What is commonly referred to as “REST” isn’t actually REST, and trying to cram that round peg into that square hole is a hobgoblin of little minds IMO. In practice, “REST” can be simplified to RPC over HTTP using JSON as a wire format. Or you can use gRPC and get strong typing and explicit RPC semantics instead.
It's not just using JSON as a wire format, it's overloading HTTP verbs and status codes as part of your protocol.
HTTP verbs and status codes map fairly cleanly to CRUD and, more generally, the "state transfer" paradigm. For generic RPC, though? Tends to get quite a bit messier.
While that’s true in the general case, there’s some rules of thumb that get you most of the way there. Use GET for read-only, side-effect-free operations and POST for everything else. Return 2xx for success, 4xx for “client error”, and 5xx for “server error”. Use Swagger to document payload formats and expected response codes. Getting too much farther beyond that is a slippery slope that leads straight to the REST hobgoblin, who is a mere distraction from the dragons a service owner actually needs to battle.
Comments
What is commonly referred to as “REST” isn’t actually REST, and trying to cram that round peg into that square hole is a hobgoblin of little minds IMO. In practice, “REST” can be simplified to RPC over HTTP using JSON as a wire format. Or you can use gRPC and get strong typing and explicit RPC semantics instead.
It's not just using JSON as a wire format, it's overloading HTTP verbs and status codes as part of your protocol.
HTTP verbs and status codes map fairly cleanly to CRUD and, more generally, the "state transfer" paradigm. For generic RPC, though? Tends to get quite a bit messier.
While that’s true in the general case, there’s some rules of thumb that get you most of the way there. Use GET for read-only, side-effect-free operations and POST for everything else. Return 2xx for success, 4xx for “client error”, and 5xx for “server error”. Use Swagger to document payload formats and expected response codes. Getting too much farther beyond that is a slippery slope that leads straight to the REST hobgoblin, who is a mere distraction from the dragons a service owner actually needs to battle.