Myths

[philsturgeon]

REST is about CRUD

REST is no more about CRUD than any other paradigm is. RPC and Query Languages can be used for CRUD or use-case driven APIs, and researching use cases will produce an API more appropriate for the users who use cases you gathered. APIs are about balancing use cases with reusability, and not about overly normalizing your data to the point where its just a JSON version of your DB. https://medium.com/@__xuorig__/the-tension-between-data-use-case-driven-graphql-apis-8f982198653b

REST is tied to HTTP/1

Some folks who use gRPC think you need to use gRPC to get the benefits of HTTP/2?

• REST can operate over HTTP/1.1, HTTP/2, or HTTP/3 if you like. HTTP/2 server push handles multiplexing just like gRPC, and HTTP/2 Server Push is also the basis for GraphQL/Apollo's @defer keyword

REST means huge responses

• Maybe you've bloated multiple resources into a single resource. Stop designing around a network hack. https://apisyouwonthate.com/blog/lets-stop-building-apis-around-a-network-hack

• Maybe you've stuck to a purely additive approach, never evolving away from a broken model, and never deprecating single properties. gRPC and GraphQL both recommend deprecating properties, and you can do the same with OpenAPI and JSON Schema, in SDKs, docs, typescript in backend code, etc. https://apisyouwonthate.com/blog/api-evolution-for-rest-http-apis/

REST cannot handle real-time

• Webhooks exist in most REST APIs to push our updates to other servers

• GraphQL Subscriptions are generally implemented over Web Sockets, and nothing about building a REST API says you cannot use Web Sockets. Go wild.

REST does not have a type system

• It does https://apisyouwonthate.com/blog/why-do-people-dislike-json/
• JSON Schema handles more than basic types "oooh its a string? how exciting" and moves into providing contract-driven server and client validation: https://www.apisyouwonthate.com/blog/server-side-validation-with-api-descriptions/

"Stateless" means...

REST is "stateless" in that sessions should not be sticky between servers, which helps ensure load balancers can do their job without things folks needing to log in and log out. Each message should contain the means to authenticate the user, such as HTTP Digest, OAuth credentials, Bearer token, JWT, etc.

REST is however for designing state machines. https://apisyouwonthate.com/blog/representing-state-in-rest-and-graphql