[HN Gopher] The Design of Everyday APIs (2022)
       ___________________________________________________________________
        
       The Design of Everyday APIs (2022)
        
       Author : resiros
       Score  : 89 points
       Date   : 2024-04-21 15:28 UTC (7 hours ago)
        
 (HTM) web link (www.roguelynn.com)
 (TXT) w3m dump (www.roguelynn.com)
        
       | chiefalchemist wrote:
       | Not to jump off topic, but my takeaway from Norman's "The Design
       | of Everyday Things" was that design is of process of compromises.
       | Could be time, could be budget, could be other factors within the
       | company, etc. But there are almost always unseen forces the
       | public isn't aware of that impacts the design they do see.
       | 
       | I would presume APIs are no different. There is no objective and
       | absolute perfect API. Instead there are always tradeoffs, always
       | compromises.
        
         | klysm wrote:
         | I've been contemplating something along these lines for a bit:
         | Step one is to understand the tradeoff space. Step two (which
         | is sometimes much more difficult) is picking where in the
         | tradeoff space makes sense for the business, but now and into
         | the future.
        
           | chiefalchemist wrote:
           | > but now and into the future.
           | 
           | That's tough. The context is always changing. The future
           | looks different every week or two. Worth considering but it's
           | also easy to go down the rabbit hole of over anticipating,
           | over planning, etc.
           | 
           | Be wise. Be thorough. But be aware you'll be wrong often
           | (when it comes to predicting the future).
        
             | hinkley wrote:
             | The best predictors don't scout all roads, they instead
             | avoid decisions that cut them off.
             | 
             | We still have a legacy of bad design we were chasing in the
             | 00's and well into the 10's of trying to future proof
             | things when what we should have been doing was hedging by
             | putting off decisions we cannot change as long as we
             | possibly can: the Last Responsible Moment is too often
             | conflated with YAGNI - things like building infrastructure
             | "you don't need yet" (need is open to interpretation and a
             | clogged roadmap full of long runways often means that
             | targets of opportunity should be pursued when the trail is
             | hot, not when the "time is right". There is never time,
             | only opportunity). When instead I think it is more about
             | jumping off ledges with no trail back. I cannot reverse
             | this decision, so I should avoid it as long as I reasonably
             | can.
             | 
             | Stall until there is more information, until your tools are
             | better, until the requirements are clear, until workarounds
             | and interim solutions do not suffice and you _must_ commit.
             | 
             | Stall, study, scaffold.
        
       | esafak wrote:
       | recording: https://www.youtube.com/watch?v=0qYDmm1O7hc
        
       | bloopernova wrote:
       | Slightly API related rant:
       | 
       | I just wanted to get my free/busy info from office 365. I wanted
       | to control a "do not disturb" light without using a phone app.
       | There doesn't seem to be any straightforward method to "generate
       | a token, save it in Bruno or Postman etc, then POST to a specific
       | endpoint". The docs I saw talk about registering an app, and all
       | sorts of heavyweight stuff in Azure.
       | 
       | Why can't I just call some URL, or add a webhook somewhere and be
       | done with it?
        
       ___________________________________________________________________
       (page generated 2024-04-21 23:00 UTC)