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 }.
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/123actually 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