4 ms·

I’m disappointed to see this comment. What don’t you think can be expressed with REST that can be with RPC?

lmm 5y ago
Custom verbs. REST is a recapitulation of "Execution in the Kingdom of Nouns" as a network metaprotocol rather than a programming language.
- rswail 5y ago
  YAGNI most of the time. Custom verbs change the focus to the verb. The verb is not visible because it's ephemeral during the "call". Whereas the state of the Noun is clear. Verbs are also not idempotent for the most part, whereas it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification.
  - lmm 5y ago
    > Custom verbs change the focus to the verb. Which is often what you want - a lot of things in the real world are more easily understood through verbs than nouns, which is what the essay is all about. REST says that everything has to be an entity, which is why so many "REST" APIs end up just exposing their database as CRUD rather than offering a vocabulary that actually makes sense for the domain. When nouns are the only important things in your domain then it works. When verbs are important in your domain it doesn't. > it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification. Most "REST" APIs "in the wild" don't actually do that (or, worse, do it incorrectly), so I'd question the idea that it's actually easy in practice.
- regularfry 5y ago
  REST-the-pattern encourages custom verbs. They're just a pain to nail onto HTTP.
  - rswail 5y ago
    It encourages custom verbs that are universal independent of the media type. That way, the operation of the verb (idempotency, caching, etc) can be fully specified and applies across the board. If I do a GET, I know that I can do it again without affecting the resource. I'll GET the current state of the resource identified by the URL. The RFCs define those verbs and their operation. I can rely on that spec for the way they operate.
jseban 5y ago
With RPC you can call any function by arbitrary name. That is by definition the most powerful protocol ever. Any restricted grammar will take away from that.
DeathArrow 5y ago
Maybe you can do it with REST but it would be more complicated and won't be the right tool for the job. RESTful or FIOH seems only appropriate if you design a public API. If your API isn't public, you don't need it to be RESTful. If you just need microservice communication, you don't even REST nor HTTP. We shouldn't try to deform the whole logic and actual needs to fit a few HTTP verbs.

lmm 5y ago

Custom verbs. REST is a recapitulation of "Execution in the Kingdom of Nouns" as a network metaprotocol rather than a programming language.

rswail 5y ago
YAGNI most of the time. Custom verbs change the focus to the verb. The verb is not visible because it's ephemeral during the "call". Whereas the state of the Noun is clear. Verbs are also not idempotent for the most part, whereas it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification.
- lmm 5y ago
  > Custom verbs change the focus to the verb. Which is often what you want - a lot of things in the real world are more easily understood through verbs than nouns, which is what the essay is all about. REST says that everything has to be an entity, which is why so many "REST" APIs end up just exposing their database as CRUD rather than offering a vocabulary that actually makes sense for the domain. When nouns are the only important things in your domain then it works. When verbs are important in your domain it doesn't. > it's relatively easy to ensure that the non-idempotent HTTP verbs (POST, PUT/PATCH, ignoring DELETE) can be made "repeatable" with use of etags or other unique identification. Most "REST" APIs "in the wild" don't actually do that (or, worse, do it incorrectly), so I'd question the idea that it's actually easy in practice.
regularfry 5y ago
REST-the-pattern encourages custom verbs. They're just a pain to nail onto HTTP.
- rswail 5y ago
  It encourages custom verbs that are universal independent of the media type. That way, the operation of the verb (idempotency, caching, etc) can be fully specified and applies across the board. If I do a GET, I know that I can do it again without affecting the resource. I'll GET the current state of the resource identified by the URL. The RFCs define those verbs and their operation. I can rely on that spec for the way they operate.

jseban 5y ago

With RPC you can call any function by arbitrary name. That is by definition the most powerful protocol ever. Any restricted grammar will take away from that.

DeathArrow 5y ago

Maybe you can do it with REST but it would be more complicated and won't be the right tool for the job. RESTful or FIOH seems only appropriate if you design a public API. If your API isn't public, you don't need it to be RESTful. If you just need microservice communication, you don't even REST nor HTTP. We shouldn't try to deform the whole logic and actual needs to fit a few HTTP verbs.