3 ms·

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 th

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....

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....