Live data from Hacker News

Everything I know about good API design

seangoedecke.com

111–120 of 168 posts

Re: Everything I know about good API design

#111
post #44

Earlier quoted context omitted.

I never understood why libraries also had the word API. From my understanding a library is a set of functions specific to a certain domain, such as a statistics library, for example. Then why would you need the word API? You already know it’s a library. For end points it’s a bit different. You don’t know what are they or user facing or programmer facing. I wonder if someone has a good take on this. I’m curious to lea…

To use code, you need an interface. One for programming. Specifically to build an application. Why does the type of I/O boundary matter?

Wouldn't the interface in C simply be called function headers? Why are we using the term API? It seems a word like "function signatures" would also make it clear (or just signatures or headers).

Maybe I just don't understand what the word interface means other than the GUI version of it. What's an interface in the analogue world? [2]

By the way, one person downvoted me. To that person: it's fine that you downvoted me, but also let's try to keep an open and inclusive culture?

I know it's a beginner question. I'm not a beginner, I use APIs all the time and have designed them as well. Just how I used servers without knowing for 5 years the semantic meaning behind it [1]. Understanding things deeply in that way is not my forte.

[1] Though most people still don't know that clients/servers are roles of computer programs. Many programmers conflate servers with actual hardware in the sense of "a computer can be a client of a server". Well, no a piece of code can be a client to another piece of code and a server can be a piece of code to another piece of code. They're roles, not distinct hardware.

[2] Claude mentions:

Analog World Interfaces

Door handle - The interface to a door mechanism. Whether it's a simple latch or complex electronic lock, you just turn/push the handle. An interface is basically the part you touch/use without needing to understand what's behind it.

Re: Everything I know about good API design

#112

Earlier quoted context omitted.

> While the author doesn't seem to like version based APIs very much, I always recommend baking them in from the very start of your application. You don’t really need to do that for REST APIs. If clients request application/vnd.foobar then you can always add application/vnd.foo.bar;version=2 later without planning this in advance.

If you use something like an OpenAPI generator and want to have different DTOs in your version 2, then you cannot do what you suggested.

You can specify multiple media types in OpenAPI.

Re: Everything I know about good API design

#113
post #4

While the author doesn't seem to like version based APIs very much, I always recommend baking them in from the very start of your application. You cannot predict the future and chances are there will be some breaking change forced upon you by someone or something out of your control.

> While the author doesn't seem to like version based APIs very much, I always recommend baking them in from the very start of your application. You don’t really need to do that for REST APIs. If clients request application/vnd.foobar then you can always add application/vnd.foo.bar;version=2 later without planning this in advance.

Most REST APIs don’t support that. So you don’t need versioning for APIs that already have a request type specified.

Re: Everything I know about good API design

#114
"Think about it - if you send three DELETE comments/32 requests in a row, it won’t delete three comments. The first successful request will delete the comment with ID 32, and the remaining requests will 404 when they can’t find the already-deleted comment."

Not necessarily. Many implementations return HTTP 204 for any DELETE that succeeds in the sense that the element is gone regardless if it had been there before. To me this always made much more sense than 404.

Re: Everything I know about good API design

#115

Earlier quoted context omitted.

> While the author doesn't seem to like version based APIs very much, I always recommend baking them in from the very start of your application. You don’t really need to do that for REST APIs. If clients request application/vnd.foobar then you can always add application/vnd.foo.bar;version=2 later without planning this in advance.

Most REST APIs don’t support that. So you don’t need versioning for APIs that already have a request type specified .

I’m not sure what you mean in the context of a discussion about how to design APIs. If you are the one designing an API, it’s up to you what you support.

Re: Everything I know about good API design

#116

Earlier quoted context omitted.

The quick rundown of refresh token I'm referring to is: 1. Generate your initial refresh token for the user just like you would a random API key. You really don't need to use a JWT, but you could. 2. The client sends the refresh token to an authentication endpoint. This endpoint validates the token, expires the refresh token and any prior bearer tokens issued to it. The client gets back a new refresh token and a bear…

So a refresh token on its own isn't more secure than a simple api key. You need a lot of plumbing and abuse detection analytics around it as well.

Almost every one of those benefits _doesn't_ require anything else. You need one more API endpoint to exchange refresh tokens for bearer token (over a simple static API key) and you get those benefits.

Re: Everything I know about good API design

#117
post #44

Earlier quoted context omitted.

To use code, you need an interface. One for programming. Specifically to build an application. Why does the type of I/O boundary matter?

Wouldn't the interface in C simply be called function headers? Why are we using the term API? It seems a word like "function signatures" would also make it clear (or just signatures or headers). Maybe I just don't understand what the word interface means other than the GUI version of it. What's an interface in the analogue world? [2] By the way, one person downvoted me. To that person: it's fine that you downvoted me…

> Wouldn't the interface in C simply be called function headers? Why are we using the term API? It seems a word like "function signatures" would also make it clear (or just signatures or headers).

First, to contrast the "application programmer interface" (i.e. what code has to be written to use it properly in an environment with a compiler) from the "application binary interface" (i.e. what actual bytes have to be provided in order to work with an already compiled version — important for linking, inter-process communication etc.).

Second, to be able to talk about what you actually do with the headers (i.e. what the rules are for using the code) separately from the headers themselves (i.e. just the code itself), and to abstract over other programming languages that don't work the same way.

> They're roles, not distinct hardware.

So, you already understand the value of these kinds of distinctions. A shame we haven't historically made them more consistently. (As an exercise, try to list everything that "static" can mean in every programming language you know where that's a keyword. For bonus points, contrast and compare to how the word is used in the discussion of programming language design.)

> Maybe I just don't understand what the word interface means other than the GUI version of it. What's an interface in the analogue world? ... Claude mentions:

In the world that I was recalling, when people were unfamiliar with a word, they used a resource called a "dictionary" to look them up. This provided a pre-written answer directly, rather than relying on sophisticated computer models to come up with something new every time. Admittedly, this did trend towards online use over time, in particular since this made it easier to update these resources to reflect current use patterns. But those online resources are still available, e.g. https://www.merriam-webster.com/dictionary/interface .

Even with AI expanding so far as to creep into search engines, you can still reliably obtain such definitions with search queries consisting of "define" + the word.

Re: Everything I know about good API design

#118

Most people who see "API" today only think "it's a web app I send a request to, and I pass some arguments and set some headers, then check some settings from the returned headers, then parse some returned data." But "API" means "Application Programming Interface". It was originally for application programs , which were... programs with user interfaces! It comes from the 1940's originally, and wasn't referred to for m…

You are talking in past tense, but there are still many non-web APIs. Every software library has an API. I still find it incredibly annoying that the web folks have hijacked the term "API" as a short hand for "web API".

Re: Everything I know about good API design

#119
post #26
post #20

Anyone else old enough to remember when "API" also meant something that had nothing to do with sending and receiving JSON over HTTP? In some cases, you could even make something that your users would install locally, and use without needing an Internet connection.

Well it stands for “application programming interface”, so I think it is valid to apply it to in-process interfaces as well as between-process interfaces Some applications live in a single process, while others span processes and machines. There are clear differences, but also enough in common to speak of “APIs” for both

It certainly is valid. I'm just irritated that it's taken over to the extent that it has.

Just as I am irritated that people seem to have forgotten that "applications" can potentially run completely locally, and that programs can be designed around the assumption that the "front end" (UI) and "back end" (business logic) will communicate directly (or at least exist within the same process, even if there are good reasons to set up message queues etc.).

But, you know, that's bad for business. Because that entails that the consumer might actually get to own something, even if it's just an ephemeral pattern of bits on local storage.

Re: Everything I know about good API design

#120
In 2025, leaving GraphQL out of a discussion on modern API design is like writing about web frameworks and downplaying React. It may not be right for every use case.. but it has become foundational in many serious frontend/backend architectures, and that deserves acknowledgment.

GraphQL isn’t just another protocol. It’s a paradigm shift in how we think about designing and consuming APIs. The author downplays its role, but in practice, GraphQL enables cleaner contracts between frontend and backend, encourages typed schemas, and dramatically reduces over-fetching and under-fetching. That’s not a minor point .. that’s central to what most developers care about when consuming APIs.

Regarding caching: yes, REST has traditional browser and CDN-based caching, but GraphQL is absolutely cacheable too. Tools like Apollo Client and Relay have built-in normalized caches that are far more granular and powerful than most REST setups. At the infrastructure level, persisted queries and CDN layer solutions (like GraphCDN or Stellate) further optimize caching behavior. So the claim that “you can’t cache GraphQL” is outdated at best.

Post reply on HN