4 ms·

I get the points of why people don't like REST, and especially the latency argument is quite true, however somewhat mitigated by http2. But I like that REST is

I get the points of why people don't like REST, and especially the latency argument is quite true, however somewhat mitigated by http2. But I like that REST is quite easy for developers to reason about. I actually built a websockets library (more proof of concept) [1] that uses a rest like syntax, implementing something similar to an express API. It exposes both a websockets server and http. It's FAR from anywhere near complete and just a concept. I have no doubt there are better solutions out there, but I just don't think REST is all that bad. But I do also love @burtonator's idea of maybe not using JSON, but hiding the complexity of something like RPC. [1] https://github.com/markwylde/restocket https://github.com/markwylde/restocket

denormalfloat 8y ago
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.
cryptonector 8y ago
REST is good mostly because of the ecosystem. You get to build responsive web apps and also non-interactive automation. You get to have all manner of proxies because the transport is very amenable to them. Lots and lots of tooling is available. It doesn't suck, really. But it's not like REST is so superior to RPC -- yeah, there's caching, but that could be built into an RPC layer as well, and the only reason it hasn't been is that HTTP won.

denormalfloat 8y ago

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.

cryptonector 8y ago

REST is good mostly because of the ecosystem. You get to build responsive web apps and also non-interactive automation. You get to have all manner of proxies because the transport is very amenable to them. Lots and lots of tooling is available. It doesn't suck, really. But it's not like REST is so superior to RPC -- yeah, there's caching, but that could be built into an RPC layer as well, and the only reason it hasn't been is that HTTP won.