Good idea to standardise this for vendors just like we do using CVEs for software components. This would definitely improve dealing with breaches.

This is a good list of guidelines to produce a service which is less of a pain to test locally, deploy and operate. Of course, don't take everything at face value (not all of it aged well) but it's a good source for inspiration.

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.

Neat little trick for services which you'd be running locally.

Nice return on experience of using a simple stack to serve loads of web requests.

Good exploration on how the total cost of ownership is spread depending on how is licensed the software you use and where you get your support from. I think there's one point a bit too glanced over in the analysis of the cost for the proprietary SaaS case: what's the cost of fixing a bug that affect your team? You might be a tiny fish in a large pond, good luck getting attention from support in this case.

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.

Interesting attempt at having webhooks implementation a bit more standardized. This is indeed needed, currently everyone does them in slightly different ways and sometimes the quality is debatable. If it gets adopted it'd give a good baseline.

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.

A bit basic and obvious, still a good list of things to keep in mind when designing REST APIs.

This is definitely a good musing on when not to go for "cloudy architectures". Most often people don't really need it, this needs to be properly thought out for each project. There are costs involved which you might not make sense to pay for in your context.

Definitely this, showing care is the best thing you can do in services. Otherwise you can only do a mediocre job.

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).