A larger transition coming to HTMX. Interesting choices and good lessons on how to manage the API transition.

Good reminder that it's better to design your APIs to avoid putting people in the situation of inadvertently creating a divide by zero.

It's kind of an unusual design choice... This is subtle, I think I'm still a bit on the fence regarding this one.

Just a little dive in the Rust standard library. It gives a good idea on how they pile layers to ensure safety while providing a nice API on top.

Lots of good points in there. Very much focused on web services APIs, that being said the first part also applies to libraries APIs in my opinion.

And it's not necessarily a problem. It all depends on the goal and context of the API you're building.

This is a good look at the reasons behind throttling. If you accept a less naive model than "preventing abuse", you can build a better throttling strategy.

Illustrated with the Clojure ecosystem, bit there's nothing inherently specific to the language here. If you want to ensure stability to your users, you need to manage your APIs properly and this article put forward a couple of interesting ideas.

Good musing about major version numbers and backward compatibility. It is indeed important to communicate breaking changes properly and to not have those too often.

Nice advices for API design. First time I see the term "inert" used in this context. Definitely one I should keep in mind and use when appropriate.

On the difficulties of dealing with third party APIs. How to handle failures and reach eventual consistency? A few good solutions and patterns are proposed here.

This is an easy mistake to make. I'd say the API isn't helping there either, there's an improvement to find in Cap'n'proto to make it safer.

Since quite a lot of Python code will be impacted by this, better get ready.

Interesting set of advices. There are a couple I tend to disagree or doubt they really matter though. Other than that probably worth keeping in mind.

Definitely a good principle to follow when designing APIs. Otherwise you make them less obvious and more dangerous to use.

Nicely explain how to secure your webhooks step by step.

Interesting list of advises. Most of it makes sense, I'm less convinced about avoiding the headers for the authentication mechanism though.

Good set of advises for Python APIs. Some applies more generally though.

There are many more useful codes than are generally used. We shouldn't shy away from using them when it makes sense, it also means the client side must be ready for them. Very often client code makes wrong assumptions on the possible codes.

Nice balanced post on the pros and cons of GraphQL.