←back to thread

Everything I know about good API design

(www.seangoedecke.com)
428 points ahamez | 1 comments | 24 Aug 25 19:10 UTC | HN request time: 0s | source
Show context
pixl97 ◴[24 Aug 25 21:54 UTC] No.45008158[source]▶
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.

replies(7): >>45008436 #>>45008763 #>>45009169 #>>45009423 #>>45009623 #>>45010511 #>>45010673 #
claw-el ◴[24 Aug 25 22:36 UTC] No.45008436[source]▶
If there is a breaking change forced upon in the future, can’t we use a different name for the function?
replies(7): >>45008467 #>>45008545 #>>45008580 #>>45008683 #>>45009012 #>>45009205 #>>45009223 #
pixl97 ◴[25 Aug 25 00:55 UTC] No.45009205[source]▶
Discoverability.

/v1/downloadFile

/v2/downloadFile

Is much easier to check for a v3 then

/api/downloadFile

/api/downloadFileOver2gb

/api/downloadSignedFile

Etc. Etc.

replies(2): >>45009539 #>>45009597 #
echelon ◴[25 Aug 25 02:04 UTC] No.45009539[source]▶
I have only twice seen a service ever make a /v2.

It's typically to declare bankruptcy on the entirety of /v1 and force eventual migration of everyone onto /v2 (if that's even possible).

replies(2): >>45009627 #>>45009660 #
1. pixl97 ◴[25 Aug 25 02:27 UTC] No.45009627[source]▶
I work for a company that has an older api so it's defined in the header, but we're up to v6 at this point. Very useful for changes that have happened over the years.