Guiding Principles of Great Web APIs https://buff.ly/0ZYymKZ

here's the slide deck for my #BSDC2025 talk. a great event in a beautiful part of the US.

"Traditional approaches to rate limiting APIs won’t work effectively for AI agent consumers, so some API providers have shifted to adaptive rate limiting (ARL). For example, DeepSeek employs a more dynamic and adaptive approach to rate limiting its API compared to other LLM API providers currently.

The concept of adaptive rate limiting isn’t new, but it’s evolving to address new API usage scenarios that include AI agents. Modern ARL involves a set of principles, tools, and techniques that allow systems to adjust rate limits dynamically based on context and real-time insights. It includes a combination of approaches:"

https://nordicapis.com/how-ai-agents-are-changing-api-rate-limit-approaches/

New blog post: Endless possibilities (a socio-technical API pattern) - in which I describe what unchecked API growth can look like.
(Another one for you, @einarwh)

https://sebastian-hans.de/blog/endless-possibilities/

You should configure #HTTP #caching for your #API, so you can reduce the number of requests, which increases performance and reduces resource usage. @Philsturgeon argues that designing for cacheability should be an integral part of #APIDesign: https://apisyouwonthate.com/blog/api-design-basics-cacheability/

Als jullie een API bouwen, beginnen jullie dan met het definiëren van een openapi.yaml (Open API Spec, kortweg OAS) of start je direct met programmeren?

Dat laatste is natuurlijk aantrekkelijk, maar niet altijd slim. Hoe je OAS-first werkt vind je in ons artikel van collega @dvh:

https://developer.overheid.nl/kennisbank/apis/aan-de-slag/bouw-een-api

If You’re Not Threat Modeling, Your API Is Already Vulnerable - DevX https://buff.ly/uqPiDEb

"if you care about uptime, user trust, or your job, you need to know where your API’s soft spots are. Otherwise, attackers will find them for you."

Handy API Extension Patterns https://leanpub.com/api-extension-patterns

"Starting with a clear look at strong, weak, and "mild" typing styles, the book introduces a resilient approach using structured extensions and runtime accessors that allow APIs to grow gracefully over time."

APIs Over IPAs 17: Aligning API Design to Business Outcomes with James Higginbotham, LaunchAny https://buff.ly/RIMPEex

"In this episode, Derric Gilling chats with James Higginbotham, founder of LaunchAny, about designing successful API strategies that drive business value. "

A Heads-Up: Some Older Posts Will Be Moving Behind the Paywall https://buff.ly/kPkqfZX

"Hey folks — just a quick note. Over the next few weeks, I’ll be moving some older posts behind the paywall. " -- #MikeAmundsen

API caching can save servers some serious work, cut down on costs, and even help reduce the carbon impact of an API. However, it is often considered an optimization rather than what it truly is: an integral part of API design. #ApiDesign #GreenTech https://apisyouwonthate.com/blog/api-design-basics-cacheability/

Medior PHP https://leanpub.com/b/mediorphp by Joseph Kanyo is the featured bundle of ebooks on the Leanpub homepage! https://leanpub.com #Php #Databases #Mysql #ComputerProgramming #Laravel #Symfony #Html #Refactoring #Apis #ApiDesign #books #ebooks

Four AI Superpowers: Where AI Improves Products https://buff.ly/GxlcQZu

"When using AI consider its four "superpowers": content creation, summarization, basic data analysis, and perspective taking."

"API keys are foundational elements for authentication, but relying solely on them is inherently a risky proposal.

Firstly, there’s the reality that API keys are not securely designed — they were never meant to be used as the sole form of authentication, and as such, they aren’t really built for the task. These keys can often be easily stolen, leaked, or, in some cases (especially if generated incrementally), outright guessed. An API key is suitable for tracking usage but is poor for security.

There is also the additional reality that keys in their default state lack some critical functionality. There’s not a lot of verification built-in for identity management, and what does exist offers very little in the way of granular access control.

Ultimately, solely relying on API keys is a mistake common with novice developers but frighteningly common even in advanced products.

Best Practices
Instead of relying heavily on API keys as a sole mechanism, combine those keys with additional approaches such as OAuth 2.0 or mTLS. Implement rigorous expiration and rotation policies to ensure that keys which are made public are only useful for a short amount of time. Consider more advanced approaches, such as IP whitelisting or device fingerprinting, to add another layer of security atop the API key process."

https://nordicapis.com/9-signs-youre-doing-api-security-wrong/

Spec-First or Code-First? Choosing Your OpenAPI Strategy with Quarkus vs. Spring https://myfear.substack.com/p/spec-first-or-code-first-choosing
#Java #Quarkus #APIDesign #OpenAPI

"The accompanying diagram is intended to help you quickly decide how to document an API, but particularly a REST API. The first split is just to make sure you are looking for the right kind of API.

Here is some more context to help you decide on an approach and get started."

https://gist.github.com/briandominick/3ffab6be460fbde799aa34e0a42a4299

Why Every Product Manager Must Master APIs??

https://buff.ly/42BY0VD

"I realized APIs are not just technical specs; they are full-fledged products, and designing them right is a strategic superpower."

The Information Architecture Philosophy Behind RESTful Web API Patterns and Practices Cookbook https://buff.ly/97cOvn8

I’m so excited that this book is back on track!

Build APIs You Wont Hate 2: This Time Its Serious

Roughly 80% of the internet is roughly built APIs, held together with enough duct-tape to choke all the hamsters powering it. Let's learn how to build them properly.

#apidesign
#apidevelopment

https://leanpub.com/build-apis-you-wont-hate-2

"Affordance Aversion" : The bias that makes devs resist declarative, dynamic API models (like ALPS) in favor of rigid schemas and static interfaces.

Loss Aversion + Endowment Effect = Overvaluing predictability, fearing flexibility.

Want resilient APIs? Rethink the trade-offs.

"Getting to this point isn’t unusual. Clients clearly think they’re making the call correctly, or else they would fix the endpoint themselves. Some misspellings are difficult to catch. The enum USER_RETREIVE may not be noticed from USER_RETRIEVE, especially if picking it from a list. Misspellings happen and they’re not always caught before making it to the contract. As an aside, that’s why it’s important writers routinely check development’s changes. This applies, too, to our testing calls in Postman, where manually entering endpoints and values are more pervasive.

The reason this isn’t caught is simple: We’re not expecting it.

For our testing, the call is made and we get results. We may even spot check some of them. But generally, results aren’t examined that closely. For instance, how often do you so carefully examine a returned list of 50 or 100 items? You check may check that the objects are complete but not that the list conforms to the search criteria.

The reason this happens is because of an intentional behavior on the server. This behavior is called Lenient Handling or Strict Handling."

https://robertdelwood.medium.com/understanding-query-parameter-handling-in-rest-calls-1821e0c3fa8c