4 ms·

REST is far too narrow to fully encapsulate the features necessary in even the most basic of web apps. A truly RESTful API is essentially just a database. So ap

REST is far too narrow to fully encapsulate the features necessary in even the most basic of web apps. A truly RESTful API is essentially just a database. So application backends always ends up being a JSON RPC API over HTTP. Better to formalize that with an RPC framework than zealously attempt sticking to something that is inadequate.

eyelidlessness 5y ago
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.
strictfp 5y ago
I disagree. The idea with REST is to push state to the backend, and add links to substates, so that the protocol doesn't have to be stateful, and logic is pushed to the edges of the network. SPAs breaks this principle by making webpages into fully fledged apps who do their own state tracking and navigation. This was never the intention of REST. The idea was to make the webpages themselves linkable RESTful substates of the application, and having the browser do the rest. From the SPA angle, RPC might look like a good solution. But RPC in itself doesn't solve any problems except literal remoting. A RESTful API makes states linkable and removes ordering dependences from the API. Look at web frameworks which tried to make web sessions stateful. They are dealing with all the pains that REST solves.
- jseban 5y ago
  > This was never the intention of REST. Yeah so REST doesn't support what people are doing or what people want. So let's not use it if we want to succeed.
  - strictfp 5y ago
    Not true. People are trying to use the mental model of a huge stateful desktop app and apply it to the web. That's not to say it's a good idea to use that model, far from it. The web was designed to avoid it for multiple very good reasons. In fact, the success of the web has partially been attributed to those very design decisions, so it might make sense to pay attention to them.
mhoad 5y ago
Google made public their own guidelines on how they design all of their new cloud APIs a few years ago. They came to a very different conclusion while still acknowledging the same points. Their position seems to be that REST standard methods as much as possible (even when technically delivering an RPC API) and fall back to custom methods when it makes sense to do so. https://cloud.google.com/apis/design/resources https://cloud.google.com/apis/design/resources
rswail 5y ago
> A truly RESTful API is essentially just a database. Not sure where you get that from. A truly RESTful API describes resources and their state changes via media types and URLs and the use of a limited number of verbs for transferring those state changes over the API. People like to map REST to CRUD because GET looks like a SELECT, POST looks like an INSERT, PUT looks like an UPDATE and DELETE looks like a DELETE. But there's nothing set in stone about those mappings. An API can represent their resources however they like and use the appropriate links to URLs to represent the state changes. What the underlying persistent storage is (if any) is irrelevant.
- jseban 5y ago
  > People like to map REST to CRUD because GET looks like a SELECT, POST looks like an INSERT, PUT looks like an UPDATE and DELETE looks like a DELETE. > But there's nothing set in stone about those mappings. People use those mapping because that's what is actually happening further down the stack, when you call your RDBMS in the end.
jseban 5y ago
I agree, it's too narrow to be used for general remote procedure calls, and an incredibly primitive database compared to the alternatives. Imagine having a web socket directly to an RDBMS being able to call any stored procedure, you would do backflips around teams arguing over REST API:s.
- DeathArrow 5y ago
  >Imagine having a web socket directly to an RDBMS being able to call any stored procedure, you would do backflips around teams arguing over REST API:s. Doing that will make REST zealots judge you for heresy.
  - jseban 5y ago
    > Doing that will make REST zealots judge you for heresy. Yeah but why are people REST zealots I don't understand. Why are developers allowed to have "strong opinions" that align with goals of people outside of the organisation, that conflict with the organisations goal, isn't that misconduct
    - DeathArrow 5y ago
      For the same reasons they use OOP, design patterns, SOLID and JS frameworks: they are popular.

eyelidlessness 5y ago

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.

strictfp 5y ago

I disagree. The idea with REST is to push state to the backend, and add links to substates, so that the protocol doesn't have to be stateful, and logic is pushed to the edges of the network. SPAs breaks this principle by making webpages into fully fledged apps who do their own state tracking and navigation. This was never the intention of REST. The idea was to make the webpages themselves linkable RESTful substates of the application, and having the browser do the rest. From the SPA angle, RPC might look like a good solution. But RPC in itself doesn't solve any problems except literal remoting. A RESTful API makes states linkable and removes ordering dependences from the API. Look at web frameworks which tried to make web sessions stateful. They are dealing with all the pains that REST solves.

jseban 5y ago
> This was never the intention of REST. Yeah so REST doesn't support what people are doing or what people want. So let's not use it if we want to succeed.
- strictfp 5y ago
  Not true. People are trying to use the mental model of a huge stateful desktop app and apply it to the web. That's not to say it's a good idea to use that model, far from it. The web was designed to avoid it for multiple very good reasons. In fact, the success of the web has partially been attributed to those very design decisions, so it might make sense to pay attention to them.

mhoad 5y ago

Google made public their own guidelines on how they design all of their new cloud APIs a few years ago. They came to a very different conclusion while still acknowledging the same points. Their position seems to be that REST standard methods as much as possible (even when technically delivering an RPC API) and fall back to custom methods when it makes sense to do so. https://cloud.google.com/apis/design/resources https://cloud.google.com/apis/design/resources

rswail 5y ago

> A truly RESTful API is essentially just a database. Not sure where you get that from. A truly RESTful API describes resources and their state changes via media types and URLs and the use of a limited number of verbs for transferring those state changes over the API. People like to map REST to CRUD because GET looks like a SELECT, POST looks like an INSERT, PUT looks like an UPDATE and DELETE looks like a DELETE. But there's nothing set in stone about those mappings. An API can represent their resources however they like and use the appropriate links to URLs to represent the state changes. What the underlying persistent storage is (if any) is irrelevant.

jseban 5y ago
> People like to map REST to CRUD because GET looks like a SELECT, POST looks like an INSERT, PUT looks like an UPDATE and DELETE looks like a DELETE. > But there's nothing set in stone about those mappings. People use those mapping because that's what is actually happening further down the stack, when you call your RDBMS in the end.

jseban 5y ago

I agree, it's too narrow to be used for general remote procedure calls, and an incredibly primitive database compared to the alternatives. Imagine having a web socket directly to an RDBMS being able to call any stored procedure, you would do backflips around teams arguing over REST API:s.

DeathArrow 5y ago
>Imagine having a web socket directly to an RDBMS being able to call any stored procedure, you would do backflips around teams arguing over REST API:s. Doing that will make REST zealots judge you for heresy.
- jseban 5y ago
  > Doing that will make REST zealots judge you for heresy. Yeah but why are people REST zealots I don't understand. Why are developers allowed to have "strong opinions" that align with goals of people outside of the organisation, that conflict with the organisations goal, isn't that misconduct
  - DeathArrow 5y ago
    For the same reasons they use OOP, design patterns, SOLID and JS frameworks: they are popular.