re: No REST for the wicked VIEW POST

FULL DISCUSSION
 

The tradeoffs you make with GraphQL are, I think, too much for most apps. The idea that you need a query parser and optimizer just to get data from your server is great for huge companies with teams of developers like facebook, but it's not great for indie hackers or small teams. REST is good enough.

Also have you seen this?

slideshare.net/landlessness/teach-...

It's quite old, but it really cleared up my confusion around REST.

 

The slides are espousing CRUD over HTTP. Slide literally says "verbs are bad". It's fine if you need to expose a database over HTTP. But it is going to be hard to make an application API out of it. Most of the things that add value in business are verbs, and the 4 from CRUD are just not enough. You'll have to sneak those verbs in somewhere (url, header, payload content), or your API will become unintelligible. Example, does DELETE /orders/123 actually delete the order or cancel it? Should I label this as "Cancel" or "Delete" in the UI? I doubt most businesses will want to delete them, but maybe this one does, I dunno. This is accidental complexity. REST has a comprehensive answer for this, which uses hypermedia to expose operations as url/method/form/headers that need to be send back to perform the operation. So you first get the resource and then you know what operations you can perform on it. But the effort to implement this is pretty large. Versus just reading through the list of messages you can send to the API and choosing: POST /ordering/CancelOrder { orderId = 123 }.

 

exactly my point, I don't know if graphQL is the good way, personally I believe more in a simple well designed json RPC :)

But that's the disappoint with REST

code of conduct - report abuse