4 ms·

REST is a good fit if the operations you want to do are CRUD, or if the data model you have is hierarchical. This is for most people, but it breaks down when

REST is a good fit if the operations you want to do are CRUD, or if the data model you have is hierarchical. This is for most people, but it breaks down when there involve multiple steps. A bank transaction is a good example, because it involves multiple updates that need to be done atomically. Mapping this to REST is complex. It's possible of course, but more complicated than the equivalent RPC counterpart. Hence, REST is not better in some common cases.

anentropic 8y ago
REST resources don't have to map 1-to-1 with your db tables The transaction itself can be a resource This seems almost maybe an argument against taking microservices too far until a single service can't own the whole transaction
- vidarh 8y ago
  This is a great point, and I think this is a major point of confusion with REST. People think of resources as a table or row with CRUD operations rather than in the wider sense as an object with a generic set of operations to trigger transitions to a new state. It's worth reiterating that REST operations are conceptually much more generic than CRUD. Nothing says that what you GET or PUT/POST need correspond directly to attributes of an object or columns in a database - in the widest sense they simply represent the current state of a resource and a state transition you wish to invoke respectively. The point is not to (only) encode persistent state, but any state. In a sense representing state that is not persisted on the server is more essential - resources that are persistent on the server can be operated on without always sending the full state. But information that is not persisted on the server needs to be encoded and transmitted with the request/response in some way.
- Dowwie 8y ago
  So, all of this new tech exists because people have issues with using a resource as an abstraction?
Dowwie 8y ago
Elaborate on your bank transaction example. Have you written one, professionally? Banks have done fine with REST.
- denormalfloat 8y ago
  Yes, I implemented a karma system on my website, where users could give karma from one person to another. It involved a bunch of things, like creating notifications, persisting the transaction to a table, etc. Doing it with REST involves making a /transaction/ endpoint, where all the operation at done, and a final /transaction/commit POST. It's ugly and not obviously correct.

anentropic 8y ago

REST resources don't have to map 1-to-1 with your db tables The transaction itself can be a resource This seems almost maybe an argument against taking microservices too far until a single service can't own the whole transaction

vidarh 8y ago
This is a great point, and I think this is a major point of confusion with REST. People think of resources as a table or row with CRUD operations rather than in the wider sense as an object with a generic set of operations to trigger transitions to a new state. It's worth reiterating that REST operations are conceptually much more generic than CRUD. Nothing says that what you GET or PUT/POST need correspond directly to attributes of an object or columns in a database - in the widest sense they simply represent the current state of a resource and a state transition you wish to invoke respectively. The point is not to (only) encode persistent state, but any state. In a sense representing state that is not persisted on the server is more essential - resources that are persistent on the server can be operated on without always sending the full state. But information that is not persisted on the server needs to be encoded and transmitted with the request/response in some way.
Dowwie 8y ago
So, all of this new tech exists because people have issues with using a resource as an abstraction?

Dowwie 8y ago

Elaborate on your bank transaction example. Have you written one, professionally? Banks have done fine with REST.

denormalfloat 8y ago
Yes, I implemented a karma system on my website, where users could give karma from one person to another. It involved a bunch of things, like creating notifications, persisting the transaction to a table, etc. Doing it with REST involves making a /transaction/ endpoint, where all the operation at done, and a final /transaction/commit POST. It's ugly and not obviously correct.