The land before modern APIs

Same here, I hate when API is used to denote Web APIs, which are only a subset.

> While in one sense an API is a compact between two or more pieces of technology, it’s ultimately a compact between two or more people.

Also the author could have re-read its article before publishing.

It seems to be the same reason as of why "How to exit vim?" was generating .005% traffic on stackoverflow.

https://stackoverflow.blog/2017/05/23/stack-overflow-helping...

https://news.ycombinator.com/item?id=19069526

Web development has seen a boom and there are a lot of new web enthusiasts.

> I thought this would be about APIs as in APIs, that is the general concept which goes back decades, not REST APIs.

I agree, the description is not ambiguity-free. However do keep in mind that in web development the concept of an API is rather unambiguous.

REST is an architectural style and while the decision to use the style may lead to "lock in", it in and of itself does not given it's a choice to use it or not.

Not sure I follow. Why is REST lock in? Because it can only be used in a single service?

S3 API for example is probably a counter example. But it shows that the lock in is not inherent to REST, no?

> My largest gripe with REST is that it's a very lock-in technology.

I can't really think of a technology less subject to lock-in than REST; reliance on specified resource representations and HATEOAS makes it agnostic to pretty much everything.

EDIT: I guess there's lock-in in the sense that once you have REST, everything else is too limiting.

> Once we evolve past REST

Few things even reach REST, much less evolve past it.

> instead of being able to decouple cleanly from the underlying protocol

REST starts out decoupled from the underlying protocol(s), it's not something you need to do when evolve past REST.

> Everything should have been focused on the payloads, not the transport layer.

The only thing that REST says about the transport layer is that one should avoid altering or extending the semantics of the underlying transport protocol(s) except as necessary to cover gaps that have no suitable coverage. REST is all about the payloads plus HATEOAS.

On top of what others have already said: GraphQL is a "clean break" that breaks with everything: idempotency (POST requests are not idempotent), caching (POST requests cannot be cached), version control and partial updates (GraphQL eschews ETags), etc. etc. etc. There is value in underlying protocols and there's value in using those protocols. GraphQL servers end up re-implementing, poorly, half of HTTP, and patting themselves on the back for it.

Edit: for those interested, here's HTTP decision diagram that REST takes full advantage of: https://github.com/for-GET/http-decision-diagram/tree/master...

I'm not sure what's your personal definition of REST but REST according to Roy Fielding's definition is an architectural style that helps design APIs that are as loosely coupled as it gets. In fact, I'm not sure what style of APIs you feel improves upon REST on this criteria.