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.

There's really something rotten in this AI "arms race"... they're clearly making mistakes to go fast for PR purposes and using tools the wrong way. This can only lead to large scale disinformation if they don't correct course quickly. This has more political impacts than it looks at first sight.

I don't quite subscribe to some of the terms used (even though I see the point of not calling this API). Still I think this is a very good way to approach design, it's also why I like TDD, the tests force you to see how the code is used. If it ain't pretty there's a problem.

Nothing groundbreaking regarding web service APIs, but a very reasonable list nonetheless.

Nice application for testing APIs.

That looks like an interesting way to share data between applications. Reminds a bit of the semantic web movement back in early 2000s (talking entities and aggregates), maybe less heavy on the schema side though. I'd need to look at the specification more.

A bit on the fence with this still... but that sounds like an interesting path to explore in dealing with service APIs. A DSL with a code generator allows to neatly separate concerns if done properly. I wonder where the catches are (apart from the obvious strong coupling to Golang in that particular case).