3 ms·

Nah, the next frontier is more likely everyone fully consolidating around REST as it stands today. This looks like movement for movement's sake, instead of impr

Nah, the next frontier is more likely everyone fully consolidating around REST as it stands today. This looks like movement for movement's sake, instead of improving developer ergonomics in an increasingly predictable world. This is like everyone finally agreed on a plug type, and someone starts to push 3 phase. Let's get all the houses wired up, instead.

chewchew 10y ago
Have you ever actually used it? It does greatly improve developer ergonomics on the client side. Check out Apollo + React (or another framework).
zimablue 10y ago
I don't know enough to justify my opinion but I really really don't get REST. Having recently had to learn a lot of web stack in a short time REST was one of the most confusing parts, and I think it's because it intrinsically doesn't make sense. I have a client and a server, they need to share a language so that the client can tell the server what do do. REST seems like jumping from that situation to a situation where you have an object hierarchy modelled as a tree and can only perform CRUD. But why? As in the article, what if I have operations which only make sense as a combination of CRUDs on different objects? What if my type system doesn't map nicely to a tree? Why am I forcing this interface through a step of serializing it into a set of actions that it doesn't naturally map to and don't individually make sense? In most programming languages you import a library with a set of functions or classes, and call them with parameters (binding on key-value or order or both). If the server is to my client side another library, why do I impose CRUD on every operation and pretend that this makes sense? It's like a programming language where instead of calling a function, you have four modes of calling a function which must map to CRUD, (these have different conventions for the same thing (body vs querystring)) although there are no guarantees that they actually do map to CRUD lots of people don't follow the convention properly and everyone insists that you must try to adhere to it as purely as possible in the name of "standardization".
- dragonwriter 10y ago
  > REST seems like jumping from that situation to a situation where you have an object hierarchy modelled as a tree and can only perform CRUD. But why? Because, frankly, most people doing "REST" don't understand REST. While URLs can imply a tree structure, REST does not give URLs any meaning besides resource identifiers; relations are communicated in resource representations not URLs and can be any model you like. There is a sense in which operations are essentially CRUD-like but, in the database analogy, it's CRUD operations against views with arbitrarily complex definitions, and trigger logic for operations other than reads, not CRUD against base tables. > As in the article, what if I have operations which only make sense as a combination of CRUDs on different objects? Then, most likely, you have a resource for the operation, which you create to initiate the operation (or create to configure and have a specified update to trigger.) > What if my type system doesn't map nicely to a tree? Then you don't use a tree representation REST doesn't need URLs as anything other thab opaque identifiers and resource representations can communicate any relationship structure you want. > If the server is to my client side another library, why do I impose CRUD on every operation and pretend that this makes sense? Well, one, CRUD against resources with unconstrained definitions is part fairly flexible and universal model, so it probably makes sense as long as you don't artificially constrain the model, and second, REST isn't always the right choice anyway. There is nothing wrong with doing RPC or other non-REST things (and it would be better if we could accept that so people could stop feeling obligated to say that the non-REST things they are doing are "REST" and muddying the waters.)
- jkaptur 10y ago
  In case you're not aware, the design you're proposing is generally called "RPC" (remote procedure call). In many ways, it's much more intuitive, but there are tradeoffs. This article might make interesting reading: http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/ http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-r....
brandur 10y ago
> Nah, the next frontier is more likely everyone fully consolidating around REST as it stands today. This looks like movement for movement's sake, instead of improving developer ergonomics in an increasingly predictable world. I certainly agree with the plug idea -- consistency is very good -- but I think that we should really consider what REST is actually buying us at the end of the day. Most people prefer to integrate through a well-maintained SDK where one is available rather than shelling out to HTTP directly (imagine calling the APIs of something like AWS over raw HTTP), and if that's fairly widespread, it might not be too bad of a thing to start moving the underlying transmission protocol of those SDKs over to something that's more flexible and more efficient (like GraphQL, but also maybe other things). A comparable analog might be when Google experimented with replacing TCP and TLS with a new protocol called QUIC that operates over UDP [1]. Because QUIC still exposes an HTTP/2 API, providers and server-side infrastructure could potentially move over to it relatively painlessly. [1] https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/ https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp...

chewchew 10y ago

Have you ever actually used it? It does greatly improve developer ergonomics on the client side. Check out Apollo + React (or another framework).

zimablue 10y ago

I don't know enough to justify my opinion but I really really don't get REST. Having recently had to learn a lot of web stack in a short time REST was one of the most confusing parts, and I think it's because it intrinsically doesn't make sense. I have a client and a server, they need to share a language so that the client can tell the server what do do. REST seems like jumping from that situation to a situation where you have an object hierarchy modelled as a tree and can only perform CRUD. But why? As in the article, what if I have operations which only make sense as a combination of CRUDs on different objects? What if my type system doesn't map nicely to a tree? Why am I forcing this interface through a step of serializing it into a set of actions that it doesn't naturally map to and don't individually make sense? In most programming languages you import a library with a set of functions or classes, and call them with parameters (binding on key-value or order or both). If the server is to my client side another library, why do I impose CRUD on every operation and pretend that this makes sense? It's like a programming language where instead of calling a function, you have four modes of calling a function which must map to CRUD, (these have different conventions for the same thing (body vs querystring)) although there are no guarantees that they actually do map to CRUD lots of people don't follow the convention properly and everyone insists that you must try to adhere to it as purely as possible in the name of "standardization".

dragonwriter 10y ago
> REST seems like jumping from that situation to a situation where you have an object hierarchy modelled as a tree and can only perform CRUD. But why? Because, frankly, most people doing "REST" don't understand REST. While URLs can imply a tree structure, REST does not give URLs any meaning besides resource identifiers; relations are communicated in resource representations not URLs and can be any model you like. There is a sense in which operations are essentially CRUD-like but, in the database analogy, it's CRUD operations against views with arbitrarily complex definitions, and trigger logic for operations other than reads, not CRUD against base tables. > As in the article, what if I have operations which only make sense as a combination of CRUDs on different objects? Then, most likely, you have a resource for the operation, which you create to initiate the operation (or create to configure and have a specified update to trigger.) > What if my type system doesn't map nicely to a tree? Then you don't use a tree representation REST doesn't need URLs as anything other thab opaque identifiers and resource representations can communicate any relationship structure you want. > If the server is to my client side another library, why do I impose CRUD on every operation and pretend that this makes sense? Well, one, CRUD against resources with unconstrained definitions is part fairly flexible and universal model, so it probably makes sense as long as you don't artificially constrain the model, and second, REST isn't always the right choice anyway. There is nothing wrong with doing RPC or other non-REST things (and it would be better if we could accept that so people could stop feeling obligated to say that the non-REST things they are doing are "REST" and muddying the waters.)
jkaptur 10y ago
In case you're not aware, the design you're proposing is generally called "RPC" (remote procedure call). In many ways, it's much more intuitive, but there are tradeoffs. This article might make interesting reading: http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/ http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-r....

brandur 10y ago

> Nah, the next frontier is more likely everyone fully consolidating around REST as it stands today. This looks like movement for movement's sake, instead of improving developer ergonomics in an increasingly predictable world. I certainly agree with the plug idea -- consistency is very good -- but I think that we should really consider what REST is actually buying us at the end of the day. Most people prefer to integrate through a well-maintained SDK where one is available rather than shelling out to HTTP directly (imagine calling the APIs of something like AWS over raw HTTP), and if that's fairly widespread, it might not be too bad of a thing to start moving the underlying transmission protocol of those SDKs over to something that's more flexible and more efficient (like GraphQL, but also maybe other things). A comparable analog might be when Google experimented with replacing TCP and TLS with a new protocol called QUIC that operates over UDP [1]. Because QUIC still exposes an HTTP/2 API, providers and server-side infrastructure could potentially move over to it relatively painlessly. [1] https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/ https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp...