> Both RPC and REST use HTTP protocol which is a request/response protocol.
Neither REST nor RPC is tied to HTTP at all. I think the title alone of section 6.3 of Fielding's dissertation, "REST Applied to HTTP", [1] should be enough to convince anybody that they're completely orthogonal concepts, much less the rest of the actual dissertation. The Wikipedia article for RPC [2] also provides numerous examples of RPC implementations that never even touch TCP, much less HTTP.
REST is literally just transferring some state via a representation. RPC is literally just calling a procedure remotely.
Also, yes, hatred of expecting different behaviors from different verbs is irrational. Because verbs indicate actions, and different verbs indicate different actions. It works well in written/spoken language, and it works well in REST and HTTP.
Also, yes, hatred of expecting different behaviors from different verbs is irrational.
To be fair, you've kind of rephrased her point into a strawman that's simply opposed to the abstract concept of verbs.
Most of the time, people understand URLs as a one-to-one mapping - each URL has only one meaning, one website. It's not until you actually start writing code to create or consume an HTTP API that you need to learn the concept of the different verbs. In spoken language you don't become functionally fluent with the language and then some time later have a new concept of verbs introduced. So I can understand why the idea that "actually a URL (the part that everyone sees and knows) can have multiple meanings based on this hidden parameter" can feel wrong.
But REST is RPC. I've read the article and the author basically defines RPC as a HTTP API that doesn't use the HTTP methods in a semantically correct manner but that's not what RPC is. RPC is any remote procedure call. It doesn't even have to be HTTP-based. Message queues are an example of something that's not RPC.
I agree with you. Too many get carried away with REST and don't think beyond HTTP.
I do appreciate the author's work here, I think the author was trying to help people clarify that REST/RPC don't need to be exclusive and that is helpful. All too often we encounter developers who want to sound smart and cool and state that it is "this tech" or "that tech" or NOTHING!
At a higher level of abstraction, representational state transfer should have nothing to do with HTTP semantics. It just so happens that we attribute REST with being related to HTTP semantics. But you could do REST with a non-HTTP protocol, if you wanted, why not?
Similarly, you can use a non-HTTP protocol in any other kind of framework for network based communication that you wanted...
And it just so happens that RPC is exposing functional, encapsulated units of code via network protocols and TCP/UDP sockets.
I remember trying to write my own network protocols for fun before over TCP and UDP sockets. Simple things like an echo service or a simple client/server application protocol. Doing that helps give one context for REST, RPC, SMTP, FTP, and more - semantics, concepts and frameworks over network connectivity.
One point of doing REST instead of RPC is because you shouldn't re-invent the wheel. HTTP already has verbs and identifiers, so why create another set of verbs (the RPC methods)? REST is embracing HTTP to its fullest, RPC[overHTTP] is "just" taking advantage of HTTP's ubiquity across platforms.
[Edit: I don't mind having a few RPC-style endpoints in a REST API. The world's not a perfect square and sometimes things just don't fit the resource-driven model well. But for example, for performing logins (something which I previously did via "POST /login"), I switched to doing a "POST /sessions", because that's what a login it is: adding a new session.]
>One point of doing REST instead of RPC is because you shouldn't re-invent the wheel. HTTP already has verbs and identifiers, so why create another set of verbs (the RPC methods)?
Because HTTP's verbs weren't created with arbitrary operations in mind, but for specific, HTTP-related tasks.
I actually prefer RPC. It's not very often I'm making a call to a server that I don't want to have complex logic behind. The REST paradigm doesn't fit that (though you can wedge it in).
REST GETs are fine for getters, and I generally like REST URLs because their prettier and don't have god-function smell like you get with SOAP.
But for commands, a POST with params to distinct URLs for each command works fine.
REST as "representational state transfer" is a boolshit. The real reason it is popular - it allows to communicate via HTTP, just URLs everyone understands and many tools available, even web browser can be used.
If you remember SOAP - the crazy approach to web services promoted before REST, you understand the difference REST made.
The same way AJAX is not about XML, REST for me is not about "representational state transfer", but just about using URLs to request operations from server.
The original REST idea of using HTTP error codes and forbidding application to create its own error classes and error reporting convention just doesn't work. HTTP errors only meaningful for HTTP - a transfer protocol, not for arbitrary application.
The point of using different HTTP verbs - chaching. Don't do
GET /deleteItem?itemId=456
because it's not guaranteed to reach the sever. Use POST instead.
So, I use HTTP URLs to communicate with server, and don't care to follow REST dogmas. It's more similar to what article calls "RPC" (actually RPC is more general term, in particular including SOAP).
> The point of using different HTTP verbs - chaching. Don't do
> GET /deleteItem?itemId=456
Yes and no. Use DELETE for delete basically for that reason, but the statement that there are different verbs for caching is wrong. That's what a variety of Headers are there for. The fact that GET is in many cases cached simply is that a GET isn't there for state changes, so it doesn't matter whether it reaches the server (headers are there to tell whether it should).
That's for how things are meant to be, but I agree that it often isn't like that. Properties of HTTP were (ab)used for other things. I think that's a mixture of not understanding HTTP (in other words, not having read RFCs) and of course practical reasons.
We can see that a lot in the web in general. A lot of things get used in different, often completely wrong (as in standards breaking ways) and so things are not really coherent. That includes HTTP, HTML, CSS, ... and that's why new versions of these standards and up having a rather strong break. Caching is actually a great example if you look at HTTP/1 vs HTTP/2. But you may also be look at tags like <i> or <b> in HTML. They started out for styling, then they were discouraged and now they have a more semantic reasoning (see HTML 5's definition).
Doesn't mean that how it is used a lot is exactly bad. It actually just shows that the original ideas, the REST dogmas, etc. maybe don't fit and people use the best from RPC and REST. HTTP is used really universally, which also explains why there are things like WebSockets which barely fit with the original ideas and concepts of what HTTP is. On the other hand it worked extremely well, when you look at its popularity.
"The same way AJAX is not about XML, REST for me is not about "representational state transfer", but just about using URLs to request operations from server."
To be fair, that's kind of like saying AJAX isn't about asynchronous requests.
Fielding doesn't agree with you. But that's your interpretation, and that's fine I guess. The point with Hypermedia APIs however is the "representational state transfer" via defined relationships between the resources.
Where 'action' is something a bit more descriptive than 'PUT' or 'DELETE' or whatever. Kind of like an object-oriented api... I'm still always dealing with resources, but I have custom actions for specific use cases.
By (mostly) adhering to REST patterns you get so much stuff for free. Other developers can quickly get up to speed quickly. Client libraries are easier to write. Things like Ember Data work out of the box. I agree that every now and then doing a POST to /logout is easier than doing a DELETE /access_token/23, but a consistent API is far more worth it.
This is my approach as well. Works very well with an event-sourcing model.
It is much easier to capture user intent with
POST /api/customer/1/change-address-due-to-move
{ "address_1": "...", "address_2": "...", ... }
than with:
PUT /api/customer/1
{ "address_1": "...", "address_2": "...", ... }
Also, GET /api/resource/action is nice place for a payload describing the expected inputs to the action. Link it all together with hypermedia and you really have something ;)
Believe others are coming around to this line of thought: ThoughtWorks included "REST without PUT" onto their technology radar earlier this year.
I made the joke in my last job that REST actually stands for Reinvented Every Single Time, because we were working on our API and every bit of advice we read on REST principals seemed to either contradict or disagree with others.
In the end we made the API as REST(ful|ish) as possible and in places that we needed to be a little more flexible we tried to keep close to common practices. I think as long as your API is sane, easy to use, well documented (and tested), then users aren't going to care whether or not it is 100% RESTful.
No kidding. The debate here is a pretty funny. Make things as RESTful as you can and, by all means add additional verbs where necessary (cancel, empty, etc). The point is for your API to be easy to understand and to use by making it more like human language.
As REST is an architectural style I always preferred the phrase mock-REST, as in mock-tudor which is a physical world architectural style with similar meaning i.e. the house wasn't built with adherence to the tudor methods of architecture, but carries the surface benefits of the tudor architectural style.
One point that didn't get addressed in this article is the use of HTTP status codes to indicate the result of a request. REST encourages proper use of status codes – 404 for a missing resource, 422 for invalid data, 201 for successful resource creation, etc. – further enhancing the predictability of the API. How does RPC handle status codes?
And yet still so many API developers don't get this, or don't know about it, or don't think it's important. Generic API errors are also pretty bad; a ton I've used will just throw a 400 (or 500) with no information on why.
Eh, sorta. Send an invalid body, say an unavailable product ID, or an invalid quantity. What error will you return? HTTP codes and REST might make sense for some simple scenarios (like managing files), but it breaks down fast otherwise. Shoehorning everything into the few codes HTTP has seems pointless.
REST is great for CRUD, and easy from javascript/web pages, but it sucks for non-CRUD actions (like logout a user or reboot a machine), and it is not as friendly as RPC for consuming from client libraries.
I have designed both, and I find that the contortions you have to do to make your API RESTful is generally not worth it unless you're almost entirely CRUD and are mainly targeting the browser (and even then, you probably have a lot more nonCRUD actions than you think).
For everything else, RPC wins because you design it much like regular code.
Maybe the answer is just to use both, rather than trying to jam a square peg in a round hole.
I'd say the tricky part is modeling state transitions in REST. Rebooting is a transition between states as is logout.
Instead of defaulting to RPC, I like to try a few things:
1. Find some abstract resource that represents. POST to reboots to create a new reboot. In order to faithfully bring the resource into parity with the new state you've requested, the system reboots a machine. A GET to reboots should give you a list of previous reboots. Updating a reboot record might occasionally be necessary as well if an error occurred.
2. Model the state transition as simply another state. "Rebooting," for example, might be a state you can transfer that represents on -> off -> on.
I'll admit they don't roll off the brain as easily as calling the "reboot" procedure, but I also typically find that it brings a good amount of positives as well. For example, the ability to create reboots brings with it the ability to get a record of those reboots pretty trivially (if you're storing requests).
In my experience, it's way easier to write client apps against a REST API.
If you look at frameworks like Backbone, you can basically create models/collections for a simple CRUD app just by adding some values to a declarative hash (URI, primary key, etc.). Because everything is so predictable, it's really easy to specify a default behavior.
Granted, you could certainly do something similar with an RPC API, but I still think it would likely be harder to generalize.
A missing factor is fragility in the face of change.
RPC leads to fragile protocols. Adding arguments to a procedure or adding properties to a result can often break clients and in practice you update systems lock step.
HTTP can gracefully handle different API version requests to the same resource. REST clients are encouraged to take only what they need from the representation.
Also, I strongly disagree with the Totaling points section. Seems too "nice" to both sides.
It seems to be that many of the comments on this and other API posts recently are by people who have never had to integrate with some else's "mostly REST but only when it suits me" API.
If the API you are writing has these features:
* you are the consumer as well as the author.
* no other developer is ever going to need to understand it.
* don't care about server/proxy/library support.
by all means don't bother with REST.
But if you are doing one/some/all of the above implementing a HTTP REST architecture is going to make your life and fellow developer's lives easier. That is what specifications are for, there to make things easier for everyone.
The thing I find most frustrating about these discussions is REST is such a simple architecture with a well thought out technical reasoning. Yet people happily ignore parts of it because of some unstated preference, and develop their own architecture which other developers then have to divine.
Let's say you have to integrate with my API that uses GET /user?id=1 instead of /user/1 , How have I made your life worse? Is it going to cost you any extra time at all to code it up?
Actually, the URL pattern doesn't define if your API is RESTful or not. You can use similar URL patterns in RPC too. This would be non-RESTful:
POST /users/create
POST /users/1234/read
POST /users/1234/update
POST /users/1234/delete
Also, in REST you don't have to use this URL pattern. Just make sure that your resources have their own URLs. In addition, resources don't have to map into your database. E.g.
POST /new_address_due_to_move.php?customer_id=1234,
is RESTful, although a bit of a stretch. My line of thought is that if you would have a separate form in your web page, it should be a separate resource with it's own URL where the form data is POSTed.
If you have a 1:1:1 relationship between database models, in-memory models and the REST endpoint, and the primary purpose of the API is to manipulate these entities, there's a reasonably strong stylistic benefit to REST style. Not all applications are like this, but many bread and butter CRUD apps are.
Hmm. Seems to me that this actually relates well to the object-oriented versus functional programming "debate" - REST deals with things (like OO), RPC deals with actions (like functional).
But, in my experience, most requests consist of a "thing path" - host, resource; and then some "function" - get, update, other. POST is then the '=' - it's still a function under the hood, but because of it's commonality and interaction with language, the syntax is a little special.
In which case (and this is what I see in the APIs I most like) "the right thing to do" is to combine them, where you have pure REST when you're interacting with the object, but use RPC style when you're interacting with the object's actions.
Let's say I have some machinery exposed through an API, you might do:
GET host.com/machines/1 -> {"machine":"mixer","state":"off"}
POST host.com/machines/1?state:on -> 200
because I'm interacting with its state. But if I need to interact with its functional actions:
POST host.com/machines/1/mix?substance1=h20&substance2=c02
it makes more sense to phrase it as an action. "I want you to start doing this". You could also phrase as a request for a state transition:
POST host.com/machines/1?state:mixing&substance1=h20&substance2=c02
but (to me) that seems way weirder, generally.
I've got to go, but I think the answers change you go from physical resources to virtual ones, say, things that process information -
GET host.com/stock_analyzer/6/analyze?ticker=GOOG
where you might control state variables regarding the analysis algorithms using a REST-style.
> If a user want to stop using your service, you’ll do this (not so obvious) call:
> DELETE /users/1234
No! It would be
DELETE /sessions/12345
or possibly
DELETE /users/1234/session
or even
DELETE /users/1234/sessions/3
in the case a user can have more than one concurrent different sessions (this is actually a fairly common case for the application we do were I work. We don't use http for this though).
Unless you actually want to permanently stop the user from using the system, in which case
The OP has essentially used circular logic: RPC is as good as REST because I know how to use it to address the issues that REST addresses (which I doubt, incidentally).
This to me is like arguing that object-oriented programming isn't really any better than procedural programming because I know how to write well-structured procedural programs. This is completely beside the point, which is that procedural programming as a style tends toward balls-of-mud programs (to simplify things), and object-oriented techniques were conceived of in order to address the characteristics of procedural programming that are the cause of this tendency.
I view RESTful API programming in a similar vein: RPC also has negative tendencies (such as the creation of fragile protocols), and REST addresses many, if not all of those. Most of the time for more people, RESTful techniques will lead to better service and API design than will RPC, just like for most of the people most of the time, object-oriented programming will lead to better programs than will procedural programming.
I'm amazed that when talking about RPC that schemas never came up. Schemas are probably my favorite part of RPCs. Let's say you have multiple services that need to communicate, but testing interoperability between the services is tricky. RPC type enforced schemas (interface definition language (IDL)) are great for this because the schemas provide guarantees that the services are communicating correctly. If a system starts seeing exceptions about IDL/schema errors, then you know right away that things are broken. Writing tests that can assume that RPC method calls will be enforced.
Another thing that struck me strange about the article is showing the RPC urls. When I was using Thrift, I never needed to think about URLs. I just needed to make sure that I was calling methods correctly.
I think RPCs are a good fit for organizations looking for a way for their service based architecture to communicate. I don't really like exposing RPCs as a public API or for web clients to interact with.
Basically, after form submit errors your location bar still says /widgets or /widgets/1 rather than /widgets/new or /widgets/1/edit, so bookmarking that page, or "like"ing it, or Ctrl-L + <Enter>ing are all broken. I'd much prefer a redirect back to the correct URL.
Also the distinction between "create" and "update" can break the back button, if the user creates something, then clicks back to edit their submission (because submitting a second time will create a second thing, not update their original thing). That's not Rails so much as REST in general.
Not sure if I 100% understand, but it sounds like maybe you want to rescue the exceptions you can think of explicitly, then
redirect_to previous_thing and return
[+] [-] andrewstuart2|10 years ago|reply
Neither REST nor RPC is tied to HTTP at all. I think the title alone of section 6.3 of Fielding's dissertation, "REST Applied to HTTP", [1] should be enough to convince anybody that they're completely orthogonal concepts, much less the rest of the actual dissertation. The Wikipedia article for RPC [2] also provides numerous examples of RPC implementations that never even touch TCP, much less HTTP.
REST is literally just transferring some state via a representation. RPC is literally just calling a procedure remotely.
Also, yes, hatred of expecting different behaviors from different verbs is irrational. Because verbs indicate actions, and different verbs indicate different actions. It works well in written/spoken language, and it works well in REST and HTTP.
[1]https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluati...
[2]https://en.wikipedia.org/wiki/Remote_procedure_call
[+] [-] resu_nimda|10 years ago|reply
To be fair, you've kind of rephrased her point into a strawman that's simply opposed to the abstract concept of verbs.
Most of the time, people understand URLs as a one-to-one mapping - each URL has only one meaning, one website. It's not until you actually start writing code to create or consume an HTTP API that you need to learn the concept of the different verbs. In spoken language you don't become functionally fluent with the language and then some time later have a new concept of verbs introduced. So I can understand why the idea that "actually a URL (the part that everyone sees and knows) can have multiple meanings based on this hidden parameter" can feel wrong.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] augustl|10 years ago|reply
[+] [-] DrJokepu|10 years ago|reply
[+] [-] sixdimensional|10 years ago|reply
I do appreciate the author's work here, I think the author was trying to help people clarify that REST/RPC don't need to be exclusive and that is helpful. All too often we encounter developers who want to sound smart and cool and state that it is "this tech" or "that tech" or NOTHING!
At a higher level of abstraction, representational state transfer should have nothing to do with HTTP semantics. It just so happens that we attribute REST with being related to HTTP semantics. But you could do REST with a non-HTTP protocol, if you wanted, why not?
Similarly, you can use a non-HTTP protocol in any other kind of framework for network based communication that you wanted...
And it just so happens that RPC is exposing functional, encapsulated units of code via network protocols and TCP/UDP sockets.
I remember trying to write my own network protocols for fun before over TCP and UDP sockets. Simple things like an echo service or a simple client/server application protocol. Doing that helps give one context for REST, RPC, SMTP, FTP, and more - semantics, concepts and frameworks over network connectivity.
The OSI model still matters. http://en.wikipedia.org/wiki/OSI_model
[+] [-] xrstf|10 years ago|reply
[Edit: I don't mind having a few RPC-style endpoints in a REST API. The world's not a perfect square and sometimes things just don't fit the resource-driven model well. But for example, for performing logins (something which I previously did via "POST /login"), I switched to doing a "POST /sessions", because that's what a login it is: adding a new session.]
[+] [-] coldtea|10 years ago|reply
Because HTTP's verbs weren't created with arbitrary operations in mind, but for specific, HTTP-related tasks.
[+] [-] rozap|10 years ago|reply
[+] [-] ecopoesis|10 years ago|reply
REST GETs are fine for getters, and I generally like REST URLs because their prettier and don't have god-function smell like you get with SOAP.
But for commands, a POST with params to distinct URLs for each command works fine.
[+] [-] avodonosov|10 years ago|reply
If you remember SOAP - the crazy approach to web services promoted before REST, you understand the difference REST made.
The same way AJAX is not about XML, REST for me is not about "representational state transfer", but just about using URLs to request operations from server.
The original REST idea of using HTTP error codes and forbidding application to create its own error classes and error reporting convention just doesn't work. HTTP errors only meaningful for HTTP - a transfer protocol, not for arbitrary application.
The point of using different HTTP verbs - chaching. Don't do
because it's not guaranteed to reach the sever. Use POST instead.So, I use HTTP URLs to communicate with server, and don't care to follow REST dogmas. It's more similar to what article calls "RPC" (actually RPC is more general term, in particular including SOAP).
[+] [-] tete|10 years ago|reply
Yes and no. Use DELETE for delete basically for that reason, but the statement that there are different verbs for caching is wrong. That's what a variety of Headers are there for. The fact that GET is in many cases cached simply is that a GET isn't there for state changes, so it doesn't matter whether it reaches the server (headers are there to tell whether it should).
That's for how things are meant to be, but I agree that it often isn't like that. Properties of HTTP were (ab)used for other things. I think that's a mixture of not understanding HTTP (in other words, not having read RFCs) and of course practical reasons.
We can see that a lot in the web in general. A lot of things get used in different, often completely wrong (as in standards breaking ways) and so things are not really coherent. That includes HTTP, HTML, CSS, ... and that's why new versions of these standards and up having a rather strong break. Caching is actually a great example if you look at HTTP/1 vs HTTP/2. But you may also be look at tags like <i> or <b> in HTML. They started out for styling, then they were discouraged and now they have a more semantic reasoning (see HTML 5's definition).
Doesn't mean that how it is used a lot is exactly bad. It actually just shows that the original ideas, the REST dogmas, etc. maybe don't fit and people use the best from RPC and REST. HTTP is used really universally, which also explains why there are things like WebSockets which barely fit with the original ideas and concepts of what HTTP is. On the other hand it worked extremely well, when you look at its popularity.
[+] [-] Nemcue|10 years ago|reply
To be fair, that's kind of like saying AJAX isn't about asynchronous requests.
Fielding doesn't agree with you. But that's your interpretation, and that's fine I guess. The point with Hypermedia APIs however is the "representational state transfer" via defined relationships between the resources.
[+] [-] hessenwolf|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] bluepnume|10 years ago|reply
GET /api/resource
POST /api/resource/action
Where 'action' is something a bit more descriptive than 'PUT' or 'DELETE' or whatever. Kind of like an object-oriented api... I'm still always dealing with resources, but I have custom actions for specific use cases.
[+] [-] 3pt14159|10 years ago|reply
By (mostly) adhering to REST patterns you get so much stuff for free. Other developers can quickly get up to speed quickly. Client libraries are easier to write. Things like Ember Data work out of the box. I agree that every now and then doing a POST to /logout is easier than doing a DELETE /access_token/23, but a consistent API is far more worth it.
[+] [-] happyshadows|10 years ago|reply
It is much easier to capture user intent with POST /api/customer/1/change-address-due-to-move { "address_1": "...", "address_2": "...", ... }
than with: PUT /api/customer/1 { "address_1": "...", "address_2": "...", ... }
Also, GET /api/resource/action is nice place for a payload describing the expected inputs to the action. Link it all together with hypermedia and you really have something ;)
Believe others are coming around to this line of thought: ThoughtWorks included "REST without PUT" onto their technology radar earlier this year.
[+] [-] zzalpha|10 years ago|reply
POST /api/resource;action
As that doesn't pollute the idea that the path itself leads to a resource.
[+] [-] xirdstl|10 years ago|reply
[+] [-] leejo|10 years ago|reply
In the end we made the API as REST(ful|ish) as possible and in places that we needed to be a little more flexible we tried to keep close to common practices. I think as long as your API is sane, easy to use, well documented (and tested), then users aren't going to care whether or not it is 100% RESTful.
[+] [-] ryan-allen|10 years ago|reply
I like your approach because it avoids never ending debates.
[+] [-] kmtrowbr|10 years ago|reply
[+] [-] jalfresi|10 years ago|reply
[+] [-] qsymmachus|10 years ago|reply
[+] [-] seanp2k2|10 years ago|reply
Relevant: http://blogs.mulesoft.org/api-best-practices-response-handli...
[+] [-] MichaelGG|10 years ago|reply
[+] [-] NateDad|10 years ago|reply
I have designed both, and I find that the contortions you have to do to make your API RESTful is generally not worth it unless you're almost entirely CRUD and are mainly targeting the browser (and even then, you probably have a lot more nonCRUD actions than you think).
For everything else, RPC wins because you design it much like regular code.
Maybe the answer is just to use both, rather than trying to jam a square peg in a round hole.
[+] [-] andrewstuart2|10 years ago|reply
Instead of defaulting to RPC, I like to try a few things:
1. Find some abstract resource that represents. POST to reboots to create a new reboot. In order to faithfully bring the resource into parity with the new state you've requested, the system reboots a machine. A GET to reboots should give you a list of previous reboots. Updating a reboot record might occasionally be necessary as well if an error occurred.
2. Model the state transition as simply another state. "Rebooting," for example, might be a state you can transfer that represents on -> off -> on.
I'll admit they don't roll off the brain as easily as calling the "reboot" procedure, but I also typically find that it brings a good amount of positives as well. For example, the ability to create reboots brings with it the ability to get a record of those reboots pretty trivially (if you're storing requests).
[+] [-] jasoncrawford|10 years ago|reply
And for what it's worth, I've only found value in levels 1 and 2, not level 3.
Also, this talk by DHH helped me understand how to organize an API by creating more nouns with a restricted set of verbs, instead of proliferating verbs on a smaller set of nouns: http://www.bestechvideos.com/2007/08/12/railsconf-07-keynote...
[+] [-] hartror|10 years ago|reply
[+] [-] kevincennis|10 years ago|reply
If you look at frameworks like Backbone, you can basically create models/collections for a simple CRUD app just by adding some values to a declarative hash (URI, primary key, etc.). Because everything is so predictable, it's really easy to specify a default behavior.
Granted, you could certainly do something similar with an RPC API, but I still think it would likely be harder to generalize.
[+] [-] ozten|10 years ago|reply
RPC leads to fragile protocols. Adding arguments to a procedure or adding properties to a result can often break clients and in practice you update systems lock step.
HTTP can gracefully handle different API version requests to the same resource. REST clients are encouraged to take only what they need from the representation.
Also, I strongly disagree with the Totaling points section. Seems too "nice" to both sides.
[+] [-] hartror|10 years ago|reply
If the API you are writing has these features:
* you are the consumer as well as the author.
* no other developer is ever going to need to understand it.
* don't care about server/proxy/library support.
by all means don't bother with REST.
But if you are doing one/some/all of the above implementing a HTTP REST architecture is going to make your life and fellow developer's lives easier. That is what specifications are for, there to make things easier for everyone.
The thing I find most frustrating about these discussions is REST is such a simple architecture with a well thought out technical reasoning. Yet people happily ignore parts of it because of some unstated preference, and develop their own architecture which other developers then have to divine.
[+] [-] guelo|10 years ago|reply
[+] [-] Geee|10 years ago|reply
[+] [-] barrkel|10 years ago|reply
[+] [-] RangerScience|10 years ago|reply
But, in my experience, most requests consist of a "thing path" - host, resource; and then some "function" - get, update, other. POST is then the '=' - it's still a function under the hood, but because of it's commonality and interaction with language, the syntax is a little special.
In which case (and this is what I see in the APIs I most like) "the right thing to do" is to combine them, where you have pure REST when you're interacting with the object, but use RPC style when you're interacting with the object's actions.
Let's say I have some machinery exposed through an API, you might do:
GET host.com/machines/1 -> {"machine":"mixer","state":"off"} POST host.com/machines/1?state:on -> 200
because I'm interacting with its state. But if I need to interact with its functional actions:
POST host.com/machines/1/mix?substance1=h20&substance2=c02
it makes more sense to phrase it as an action. "I want you to start doing this". You could also phrase as a request for a state transition: POST host.com/machines/1?state:mixing&substance1=h20&substance2=c02
but (to me) that seems way weirder, generally.
I've got to go, but I think the answers change you go from physical resources to virtual ones, say, things that process information -
GET host.com/stock_analyzer/6/analyze?ticker=GOOG
where you might control state variables regarding the analysis algorithms using a REST-style.
Thoughts?
[+] [-] grandalf|10 years ago|reply
I think it's the opposite: REST deals with data, while RPC calls an operation that has side effects on some (potentially) unknown state.
Not arguing that one is better just offering my thoughts on the analogy.
[+] [-] yxhuvud|10 years ago|reply
> DELETE /users/1234
No! It would be
or possibly or even in the case a user can have more than one concurrent different sessions (this is actually a fairly common case for the application we do were I work. We don't use http for this though).Unless you actually want to permanently stop the user from using the system, in which case
would be the perfectly obvious choice.[+] [-] aggieben|10 years ago|reply
This to me is like arguing that object-oriented programming isn't really any better than procedural programming because I know how to write well-structured procedural programs. This is completely beside the point, which is that procedural programming as a style tends toward balls-of-mud programs (to simplify things), and object-oriented techniques were conceived of in order to address the characteristics of procedural programming that are the cause of this tendency.
I view RESTful API programming in a similar vein: RPC also has negative tendencies (such as the creation of fragile protocols), and REST addresses many, if not all of those. Most of the time for more people, RESTful techniques will lead to better service and API design than will RPC, just like for most of the people most of the time, object-oriented programming will lead to better programs than will procedural programming.
[+] [-] mrinterweb|10 years ago|reply
Another thing that struck me strange about the article is showing the RPC urls. When I was using Thrift, I never needed to think about URLs. I just needed to make sure that I was calling methods correctly.
I think RPCs are a good fit for organizations looking for a way for their service based architecture to communicate. I don't really like exposing RPCs as a public API or for web clients to interact with.
[+] [-] pjungwir|10 years ago|reply
http://illuminatedcomputing.com/posts/2011/07/restless-doubt...
Basically, after form submit errors your location bar still says /widgets or /widgets/1 rather than /widgets/new or /widgets/1/edit, so bookmarking that page, or "like"ing it, or Ctrl-L + <Enter>ing are all broken. I'd much prefer a redirect back to the correct URL.
Also the distinction between "create" and "update" can break the back button, if the user creates something, then clicks back to edit their submission (because submitting a second time will create a second thing, not update their original thing). That's not Rails so much as REST in general.
[+] [-] seanp2k2|10 years ago|reply