3 ms·

It's more natural to deal with collections and other data structures using RPC. REST works best with single items. As soon as you need to start generating repor

It's more natural to deal with collections and other data structures using RPC. REST works best with single items. As soon as you need to start generating reports, it can be complicated to create sane REST endpoints whereas it's trivial with RPC. REST: GET /api/item/1 GET /api/item/2 POST /api/item { name: foo, collection: 1 } POST /api/item { name: bar, collection: 1 } RPC: GET /api/items POST /api/items [{ name: foo, collection: 1 }, { name: bar, collection: 1 }]

njharman 10y ago
How are your RPC examples not REST? RPC would involve client lib. And may or may not even use HTTP as transport. api.get_product(id=1) api.add_product(details)
- bigmanwalter 10y ago
  I thought we were talking about RPC over HTTP. My RPC examples don't qualify as "proper" REST where you are only supposed to GET and POST singular resources at a time. In order to post multiple, you need a collection identifier. In REST, you can't GET "items", you can get "item1" and "item2" or you can get "collection1" to which "item1" and "item2" belong. Maybe a clearer example around running a script: REST: POST /api/action { action: do_the_thing } RPC: POST /api/do_the_thing RPC is the most basic mapping of actions > endpoints whereas REST demands you organize everything into resources.
  - mercer 10y ago
    Interesting. It sounds rather similar to me as the way the difference between functional and OO programming is often described (verbs-first vs nouns-first). Is there anything to that or am I comparing apples with non-apples?
    - bigmanwalter 10y ago
      I think there is definitely some basis to your analogy :) I think that it also stems from most ORM's focus on updating single database rows at a time even though operations frequently span across multiple rows. As all data manipulation ultimately happens on the server, I feel it's often unnecessary to keep track of individual resources in the client.
inf0rmer 10y ago
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.

njharman 10y ago

How are your RPC examples not REST? RPC would involve client lib. And may or may not even use HTTP as transport. api.get_product(id=1) api.add_product(details)

bigmanwalter 10y ago
I thought we were talking about RPC over HTTP. My RPC examples don't qualify as "proper" REST where you are only supposed to GET and POST singular resources at a time. In order to post multiple, you need a collection identifier. In REST, you can't GET "items", you can get "item1" and "item2" or you can get "collection1" to which "item1" and "item2" belong. Maybe a clearer example around running a script: REST: POST /api/action { action: do_the_thing } RPC: POST /api/do_the_thing RPC is the most basic mapping of actions > endpoints whereas REST demands you organize everything into resources.
- mercer 10y ago
  Interesting. It sounds rather similar to me as the way the difference between functional and OO programming is often described (verbs-first vs nouns-first). Is there anything to that or am I comparing apples with non-apples?
  - bigmanwalter 10y ago
    I think there is definitely some basis to your analogy :) I think that it also stems from most ORM's focus on updating single database rows at a time even though operations frequently span across multiple rows. As all data manipulation ultimately happens on the server, I feel it's often unnecessary to keep track of individual resources in the client.

inf0rmer 10y ago

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.