3 ms·

But that's not how you would use REST and RPC though, you seem to be confusing both paradigms. REST: GET /api/items (returns a list of items) GET

But that's not how you would use REST and RPC though, you seem to be confusing both paradigms. REST: GET /api/items (returns a list of items) GET /api/items/1 (returns item with id#1) POST /api/items (creates a new item, "adds" it to the list) PUT /api/items/1 (updates item with id#1, the whole resource needs to be sent) PATCH /api/items/1 (updates item with id#1, only changes in the resource need to be sent) DELETE /api/items/1 (updates item with id#1, only changes in the resource need to be sent) RPC (one possible implementation): GET /api/listItems (lists all items) POST /api/addItem (adds an item) POST /api/updateItem (updates an item, the id is in the payload) GET /api/deleteItem (deletes the item) (Verbs don't matter in RPC, I only used POST in favour of GET in the above examples because some clients and servers enforce limits on the size of GET requests.)

bigmanwalter 10y ago
Right, but RPC allows for, say, updating items 3, 4, 5, 6 in one request, whereas REST dictates that you do it over 4 separate requests. REST can also get messy if you, let's say, update all items with value > 4 as you can't PATCH /api/items/greaterthan/4 { active: false } Whereas with RPC you can easily do: POST /api/items?greaterthan=4 { active: false } In REST, you would do POST /api/item_updates/ { greatherthan: 4, active: false } It comes off as messy to me as I would prefer to keep all endpoints around manipulating a particular model within the same controller rather than having multiple controllers for each model. I find there's an impedance mismatch between what endpoints my solutions need and what REST dictates. And it requires a lot of acrobatics to map my solution onto the REST way.
- seangrogg 10y ago
  > REST dictates that you do it over 4 separate requests Can you point me to documentation that supports this claim? I've yet to see anything that expressly prohibits batched requests.
  - bigmanwalter 10y ago
    I can't find a proper reference but that is my understanding after having thoroughly researched it years ago.

bigmanwalter 10y ago

Right, but RPC allows for, say, updating items 3, 4, 5, 6 in one request, whereas REST dictates that you do it over 4 separate requests. REST can also get messy if you, let's say, update all items with value > 4 as you can't PATCH /api/items/greaterthan/4 { active: false } Whereas with RPC you can easily do: POST /api/items?greaterthan=4 { active: false } In REST, you would do POST /api/item_updates/ { greatherthan: 4, active: false } It comes off as messy to me as I would prefer to keep all endpoints around manipulating a particular model within the same controller rather than having multiple controllers for each model. I find there's an impedance mismatch between what endpoints my solutions need and what REST dictates. And it requires a lot of acrobatics to map my solution onto the REST way.

seangrogg 10y ago
> REST dictates that you do it over 4 separate requests Can you point me to documentation that supports this claim? I've yet to see anything that expressly prohibits batched requests.
- bigmanwalter 10y ago
  I can't find a proper reference but that is my understanding after having thoroughly researched it years ago.