3 ms·
It has a very solid definition (as given in the original thesis http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pub
by bct 18y ago
It has a very solid definition (as
given in the original thesis http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm ). It's blurred because a lot of people latch onto the wrong things or get it wrong and spread those misconceptions.
This introduction isn't bad: http://www.infoq.com/articles/rest-introduction http://www.infoq.com/articles/rest-introduction
In short: you have nouns and representations of nouns. You have a set of verbs that can be applied to those nouns. You discover nouns through links from other nouns. The client and the server exchange state by exchanging representations. The server doesn't need to know what the client is doing at a particular moment.
- ajross 18y agoIt's also blurred because people try to apply it to problems for which isn't not appropriate. The central theme of REST is that a single URI corresponds uniquely to a single "thing", which is then operated on using a small set of operations (basically set/get/delete). That's great, if your problem works like that. It's not great if it doesn't. Some protocols really are more appropriately modelled using "methods" on the objects, because the behavior is what matters, not so much the data itself.
- bct 18y agoCan you give an example?
- ajross 18y agoOf protocols that don't work well with REST? Sure: anything that, in the database world, would require transactions. Think of the classic double-entry accounting transaction: you have two accounts, and need to atomically subtract an amount from one and add it to the other. Clearly the accounts are two (or more) REST URIs. But the operation needs to be atomic on both; it's not enough just to do two PUT/POST operations. You can do it with REST, but it requires some fancy footwork with extra objects for "locks" or whatnot. It's just a mess. With a protocol that exposes behavior instead of state? It's just a "DEBIT" command that takes two accounts and an amount and returns success or failure. Basically: pick the tool for the job. A lot of the "problems" with REST are an attempt to make the hype more powerful than the technique.
- bct 18y agoThe RESTful way to do that would be something like: POST /transactions from: /accounts/savings to: /accounts/chequing amount: 123.45 Generally the proper way to do something atomically is to do it in a single request. REST isn't the best choice for every application - the whole point is that it has certain strengths - but it's very flexible.
- ajross 18y agoNo, no, no. That's not RESTful at all. What "thing" does /transactions represent? It's the same URI for every single account in the world? What you've done is break out of the paradigm in order to solve a particular problem, which is great. But don't call it "REST", because the whole point of this discussion is that doing so confuses people about what REST is supposed to mean.
- bct 18y agoIt's a collection of transactions. What's unRESTful about that? Collections of things are a very common REST pattern. Naturally you would also want a URI for each account, and it might make sense to have many different collections of transactions. I don't see how that breaks out of the paradigm. Edit: I'm using "transactions" as in "financial transactions" (as opposed to "database transactions")