4 ms·

REST is great for CRUD, and easy from javascript/web pages, but it sucks for non-CRUD actions (like logout a user or reboot a machine), and it is not as friendl

by NateDad 11y ago

REST is great for CRUD, and easy from javascript/web pages, but it sucks for non-CRUD actions (like logout a user or reboot a machine), and it is not as friendly as RPC for consuming from client libraries. I have designed both, and I find that the contortions you have to do to make your API RESTful is generally not worth it unless you're almost entirely CRUD and are mainly targeting the browser (and even then, you probably have a lot more nonCRUD actions than you think). For everything else, RPC wins because you design it much like regular code. Maybe the answer is just to use both, rather than trying to jam a square peg in a round hole.

andrewstuart2 11y ago
I'd say the tricky part is modeling state transitions in REST. Rebooting is a transition between states as is logout. Instead of defaulting to RPC, I like to try a few things: 1. Find some abstract resource that represents. POST to reboots to create a new reboot. In order to faithfully bring the resource into parity with the new state you've requested, the system reboots a machine. A GET to reboots should give you a list of previous reboots. Updating a reboot record might occasionally be necessary as well if an error occurred. 2. Model the state transition as simply another state. "Rebooting," for example, might be a state you can transfer that represents on -> off -> on. I'll admit they don't roll off the brain as easily as calling the "reboot" procedure, but I also typically find that it brings a good amount of positives as well. For example, the ability to create reboots brings with it the ability to get a record of those reboots pretty trivially (if you're storing requests).
- Programmatic 11y ago
  My first approach for this is to POST to a reboot/ resource which gives you a reboot/123 ID that you can continue to do a GET against to see the status of the reboot (did it start OK? Is the machine back up?).
- pjc50 11y ago
  This is the real advantage of REST - managing state transitions in any distributed system is hard, it's just that REST encourages you to think about it upfront a bit.
- NateDad 11y ago
  These are exactly the contortions I'm talking about. You're building a whole history of reboots and states and stuff, and I just build an RPC function call named "Reboot" and move on, without cluttering my API with crud (heh) like this.

by NateDad 11y ago

andrewstuart2 11y ago

I'd say the tricky part is modeling state transitions in REST. Rebooting is a transition between states as is logout. Instead of defaulting to RPC, I like to try a few things: 1. Find some abstract resource that represents. POST to reboots to create a new reboot. In order to faithfully bring the resource into parity with the new state you've requested, the system reboots a machine. A GET to reboots should give you a list of previous reboots. Updating a reboot record might occasionally be necessary as well if an error occurred. 2. Model the state transition as simply another state. "Rebooting," for example, might be a state you can transfer that represents on -> off -> on. I'll admit they don't roll off the brain as easily as calling the "reboot" procedure, but I also typically find that it brings a good amount of positives as well. For example, the ability to create reboots brings with it the ability to get a record of those reboots pretty trivially (if you're storing requests).

Programmatic 11y ago
My first approach for this is to POST to a reboot/ resource which gives you a reboot/123 ID that you can continue to do a GET against to see the status of the reboot (did it start OK? Is the machine back up?).
pjc50 11y ago
This is the real advantage of REST - managing state transitions in any distributed system is hard, it's just that REST encourages you to think about it upfront a bit.
NateDad 11y ago
These are exactly the contortions I'm talking about. You're building a whole history of reboots and states and stuff, and I just build an RPC function call named "Reboot" and move on, without cluttering my API with crud (heh) like this.