The Design of Everyday APIs (2022)
roguelynn.com
The Design of Everyday APIs (2022)
1–10 of 19 posts
Re: The Design of Everyday APIs (2022)
#2Not 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.
Re: The Design of Everyday APIs (2022)
#3recording: https://www.youtube.com/watch?v=0qYDmm1O7hc
Re: The Design of Everyday APIs (2022)
#4Not 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…
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.
Re: The Design of Everyday APIs (2022)
#5Not 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…
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.
> 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).
Re: The Design of Everyday APIs (2022)
#6Earlier quoted context omitted.
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.
> 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).
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.
Re: The Design of Everyday APIs (2022)
#7Slightly 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?
Re: The Design of Everyday APIs (2022)
#8Slightly 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,…
You can sign into Graph Explorer and get an access token there:
https://developer.microsoft.com/en-us/graph/graph-explorer
No clue how long it lasts.
Re: The Design of Everyday APIs (2022)
#9Slightly 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,…
You can sign into Graph Explorer and get an access token there: https://developer.microsoft.com/en-us/graph/graph-explorer No clue how long it lasts.
Oh, that is cool!
But corporate IT has apparently blocked being able to use graph-explorer.
Thank you anyway! :)
Re: The Design of Everyday APIs (2022)
#10Earlier quoted context omitted.
You can sign into Graph Explorer and get an access token there: https://developer.microsoft.com/en-us/graph/graph-explorer No clue how long it lasts.
Oh, that is cool! But corporate IT has apparently blocked being able to use graph-explorer. Thank you anyway! :)
Guess it’s time to scrape your calendar from web?