Why REST Failed
Representational State Transfer (REST) is the explicit architecture of HTTP and the World Wide Web. It is a well-designed, well thought out system that enables scalable applications that service millions of users. It is also a simpler system that enables developers who understand it to bring applications to market faster that perform better. Well, actually, no, it’s not. And therein lies a story.
HTTP is based on four basic operations: GET, PUT, POST, and DELETE.
- GET is used for safe operations: ones without any side effects. GETable operations can be completely specified by the URL and can be bookmarked, linked to, prefetched, cached, and otherwise optimized.
- POST is used for unsafe operations: ones that cause things to happen. You can’t even use the back button on a post without seeing a warning. For example, pressing the buy button in an online store should be a post because it causes the credit card to be charged. Pushing the buy button twice, causes you to be charged twice. That’s unsafe and shouldn’t be done by a machine without a human decision. Furthermore, a lot of the data for a POST request is actually encapsulated in the the HTTP request body, not in the URL as with a GET. Thus POST operations cannot be bookmarked, linked to, prefetched, cached, and otherwise optimized. However, POST is the most general method and can be used for almost anything.
- PUT is used to create or update a resource at a specific URL. PUT is not safe (it changes or creates a new resource) but it is idempotent. That means that if you aren’t sure if a request succeeded, try it again. PUTting the same content twice is not a problem. The end result is the same as PUTting it once. By contrast, POSTing a form twice might mean you’ve bought two copies of Oops!… I Did It Again (and one’s embarrassing enough).
- Finally DELETE is the simplest method. It deletes the resource at a specified URL. It too is idempotent, since deleting a previously deleted resource has no effect.
The beauty of REST is that those four verbs are all you need. Everything you need to do can be done with GET, PUT, POST, and DELETE. You don’t need to invent a new verb for every operation you can imagine. This make HTTP scalable, flexible, and extensible. Simplicity leads to power.
The problem is that GET, PUT, POST, and DELETE really are a minimal set. You truly do need all four, and we only have two; and I’ve never understood why. In 2006 browser vendors still don’t support PUT and DELETE. A few browsers over the years have tried to implement these as parts of editing functionality, but they’ve never allowed it in a real web application as opposed to a thick client GUI. The method of an HTML form is limited to GET and POST. PUT and DELETE are not allowed. This isn’t some failure of browser vendors to properly implement the specification either. The HTML specification only allows GET and POST as form actions. XHTML and even XForms 1.0 don’t change this. This means it’s impossible to build a fully RESTful client application inside a web browser. Consequently everyone tunnels everything through POST, and simply ignores PUT and DELETE.
I’m getting really tired of explaining REST to people, and then having to back off and say, “This doesn’t actually work yet, and there doesn’t seem to be a possibility of it working in the near future.” Why do we have to tunnel everything through POST? Why don’t HTML forms support PUT and DELETE? I’d understand it if the browser vendors had simply failed to implement the spec. Lord knows they’ve ignored enough other things in the past. But that’s not the case. Even XForms 1.0 restricted itself to GET and POST, because, hard as it is to believe, the working group couldn’t think of any use-cases for PUT and DELETE!
Fortunately, the REST train may finally be leaving the station, even if it’s years late. XForms 1.1 will allow DELETE and PUT as form actions. No mainstream browsers have yet implemented even XForms 1.0, but maybe we’ll be able to use them sometime before I retire.
If you don’t want to wait that long, you can roll your own with AJAX. It’s easy enough to set the method of an open call to PUT or DELETE:
var request = new XMLHttpRequest();
request.open("DELETE", "http://www.example.com/foo/bar.html", true); At this point you’re halfway to rolling your own thick client GUI, but at least you can deploy it inside a web browser.
If you are rolling your own thick client GUI, then your options open up a little, as long as you use an HTTP library with full support for PUT and DELETE such as the Apache HttpClient 3.0. Even java.net.HttpURLConnection will do in a pinch; and if worst comes to worst, you can always roll your own on top of raw sockets.
Of course, then you have to worry about the server side. The support is once again not as ubiquitous as it should be, but it’s a lot better than on the client. All major web servers accept PUT and DELETE requests, and most recent versions of web app frameworks like the Java Servlet API or PHP also do. Some older versions have problems, but it’s easier to upgrade your server than everybody’s client. You may have to tell the server how to handle a PUT or DELETE request, just as you have to tell it how to handle a POST. In the future, I’d like to see mainstream servers treat PUT and DELETE more like GET: that is, support them out of the box with a little basic configuration rather than requiring a script to tell them how to handle it. POST needs a script because a POST can mean almost anything, but PUT and DELETE shouldn’t require the webmaster to set up more than a simple configuration and some user names and passwords.
However, it really is the client side, that’s the problem. Right now the best option for client-side PUT and DELETE seems to be to hook up a some onClick actions that use JavaScript and XMLHttpRequest to send the right verb at the right time. It makes me gag to depend on JavaScript for anything, but there really doesn’t seem to be a better choice; nor does one seem likely soon. Wasn’t REST supposed to make things simpler?
October 26th, 2006 at 12:08 pm
Ok, so humor us: what are some PUT and DELETE use-cases, for which we currently (ab)use POST instead? I can’t think of any off the top of my head.
October 26th, 2006 at 12:21 pm
regarding your comment that servers in future should treat put and delete just like get.
according to the http spec
a. post is supposed to add new content on the server
b. put is supposed to update existing content on the server.
when this is the case, how should the server support put?
October 26th, 2006 at 2:41 pm
This is completely off-topic ,sorry.
I was just wondering which of those four books (including yours) you would recommend to someone who is familiar with web programming, but wants to understand http with a greater depth.
October 26th, 2006 at 3:42 pm
WHATWG is spec’ing this, and then (at least) Firefox+Safari+Opera will be implementing it.
http://whatwg.org/specs/web-forms/current-work/#methodAndEnctypes
October 27th, 2006 at 12:19 am
Honestly, your title looks like a big overstatement, especially looking at the content of the post which is quite accurate. I think it’s also important to mention that web browsers are not the only type of RESTL client.
You can already develop Web services that fully support REST, all four verbs and even more. Our Restlet framework (http://www.restlet.org) provides advanced support for both client-side and server-side applications, using a unified API (alternative to raw HttpUrlConnection, Apache HttpClient and Servlet API).
October 27th, 2006 at 12:20 am
[…] Why REST Failed Are urban design plans considered a failure because a tornado takes out a business park? (tags: rest design principleddesign softwarearchitecture architecture) […]
October 27th, 2006 at 4:23 am
REST is an architectural style, not a web-GUI implementation idea. REST can well be used between software components. If you want to integrated REST into browsable GUIs, the most common method is to use URL-parameters like
http://example.com/my/rest/path/file.xml?parem1=value1&x-rest-method=DELETE
No JavaScript needed. The most important thing in REST is to distinguish READ from UPDATE. READ is done using GET and can be cached, UPDATE is using PUT, POST, DELETE and cannot be cached. Tunneling PUT and DELETE over POST thus don’t change the cachability, which results in performance.
October 27th, 2006 at 7:36 am
Ever needed to add a web page to a site at a specific URL? That’s a use-case for PUT. Ever needed to correct a spelling error on a web page? PUT again. Ever needed to delete a page from a site? DELETE.
October 27th, 2006 at 7:38 am
Jagan,
Your understanding of PUT vs. POST is a common misconception. POST is for creating a resource at a server-specified URL. PUT is for creating or changing a resource at a client-specified URL. See POST vs. PUT.
October 27th, 2006 at 2:15 pm
“Wasn’t REST supposed to make things simpler?”
It does, and you know it.
October 28th, 2006 at 6:01 am
Ladies and Gentlemen, let me enlighten you as to the real reason REST is going nowhere (pun intended):
# 1 – Most important of all, if the application uses REST paths and verbs instead of generic resources and POSTs, *customers will never care*. They use bookmarks, they click hyperlinks, but they do not type into the Address box. With AJAX apps they won’t even know because they don’t see the URL at all. REST is a geek religion and it is functionally equivalent to the conventional procedural technique. So no one will pay you extra to do it the kosher way. That in itself is enough to sink REST, but there’s more.
# 2 – Secondly it makes programmers jump through an extra hoop just to get remoting to work. The ‘verb’ of a method call has never been Out-of-Band or implicit in any way – it’s right there in the name of the method. In Java it might be getItem(x), setItem(x,y), removeItem(x) etc. It’s never itemOp(‘DELETE’, x)! REST demands that programmers decode a transport-specific Out-of-band style verb into one of several possible implementation methods in the service layer, despite the increasing trend towards SOA which necessitates the exposure of the same services via several different client protocols. Why expose removeItem(x) to clients as anything other than removeItem(x)? When this procedural representation is how it is done on both an AJAX client and also in the server implemtation code, there is no point in creating an intermediate representation that requires at least one extra arbitrary parameter mapping to be defined. You could have naming conventions in your server methods to help, but then the tail is wagging the dog. Try exposing the same RESTful method through SOAP and.. oh dear. SOAP messages are meant to be intact producer-to-consumer, not TCP port to TCP port. Good thing we didn’t get on board the REST train!
# 3 – Lastly, it’s difficult to care about the wire format when there are now libraries and frameworks that do all your remoting for you. Those libraries could automatically make your app RESTful, but you’d never know. You use a library’s default method mapping because you want it all to ‘just work’ and even forget that there is an HTTP connection between client and server. It’s all about the information and the service, and because the whole dynamic content saga started with UNIX cgi-bin processes (where was the REST crowd when they were needed in 1993?) and it never had a relevant reason to change formats, that’s they way it stayed all through HTML forms and more recently AJAX.
So in short, REST doesn’t pay, REST costs, and REST is increasingly irrelevant.
October 28th, 2006 at 6:34 pm
[…] This is the clearest and most concise explanation of REST that I have yet encountered, including why it’s not all there yet. (In spite of the title it’s not really hostile to REST.) […]
October 29th, 2006 at 3:23 pm
IMO, REST components [1] not supporting two methods is not the only problem keeping us from creating RESTful web applications. I’ve encountered a few more I like to collectively call Browserland HTTP [2].
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_3
[2] http://sandeep.shetty.in/2006/04/browserland-http.html
October 30th, 2006 at 4:45 pm
Nice inflamatory headline. It’s a great way to get more people reading your article, but it makes you look petty. Some tools are better for some jobs, other tools for others.
To put it a different way, there’s a joke about a guy who is shipwrecked. Alone and starving on a deserted island he prays to God every day. Along comes a cruise ship. They throw down a rope and yell for him to climb up. But he refuses. He says faith in God will save him. Soon a helicopter comes. Same thing happens. Later a sea plane lands nearby, but still the man, nearly dead, refuses the help, claiming faith in God will save him. Eventually he dies. When he gets to heaven, the first thing he does is go to God. He says, “God, I prayed every day for you to save me. My faith was stronger than any man. What gives?” God replies, “Look buddy, I sent you a really nice cruise ship, a helicopter, and finally a sea plane. What more did you want?”
The point is, if the fact that a good solution isn’t perfect keeps you from using it, you’re not going to get anything done. Nothing is perfect. And saying that REST has failed because it is flawed is nothing but self-serving.
October 30th, 2006 at 7:03 pm
REST fails because it contains world observable updating registers (POST can be observed through GET for example).
Exactly the same reason that imperative programming fails.
October 31st, 2006 at 7:15 am
Tony, I’m afraid you’re going to have to elaborate on that one. What do you mean by, “POST can be observed through GET”?
As to imperative programming:
October 31st, 2006 at 12:03 pm
Maybe a simpler protocol could serve better than REST.
See http://www.microcalls.org
October 31st, 2006 at 10:20 pm
Blame the frameworks (commented here: http://programming.reddit.com/info/od7i/comments/codti)
November 5th, 2006 at 8:37 am
BTW: the POSTDATA screenshot from Firefox shows it’s non-conformance to RFC 2616 p13.13. That “error” should never happen.
The workaround for both Fx and IE is to send status 303 redirect in response to POST.
November 5th, 2006 at 9:49 am
[…] The Cafes » Why REST Failed Representational State Transfer (REST) is the explicit architecture of HTTP and the World Wide Web. It is a well-designed, well thought out system that enables scalable applications that service millions of users. It is also a simpler system that enables (tags: soa REST services standards) […]
November 8th, 2006 at 1:04 am
[…] Why REST Failed HTTP is based on four basic operations: GET, PUT, POST, and DELETE. […]
November 8th, 2006 at 6:54 am
We’ve been successfully RESTful in the Rails land for a while now. See introduction to Simply RESTful [1] and DHH’s keynote from this year’s Railsconf [2].
“So in short, REST doesn’t pay, REST costs, and REST is increasingly irrelevant.”
Oh, how wrong can you be. In Rails, using Simply RESTful means a RESTful API for your app for near-zero cost.
[1] http://www.ryandaigle.com/articles/2006/08/01/whats-new-in-edge-rails-simply-restful-support-and-how-to-use-it
[2] http://blog.scribestudio.com/articles/2006/07/09/david-heinemeier-hansson-railsconf-2006-keynote-address
December 29th, 2006 at 2:45 am
> In Java it might be getItem(x), setItem(x,y), removeItem(x) etc. It’s never itemOp(’DELETE’, x)!
DELETE *is* the “removeItem”. Apples, oranges.
January 31st, 2007 at 8:15 pm
I seem to have the same question as the first guy. You had replied to him saying that every time one wants to add a page or correct a spelling mistake, one might end up using PUT or DELETE. Assume I built a site like amazon.com. I am sure that *all* content is coming from database tables. And all posts made by users on amazon.com or any reviews written by users end up in database tables. In such a site, could you give an example of where one could use PUT or DELETE?
February 1st, 2007 at 7:55 am
You probably wouldn’t use a lot of PUT or DELETE on a site. It would be mostly POST for edit because you’d be asking one resource (the one you’re posting to, the interface to the database) to change the state of other resources (the pages). PUT is for more direct, unmediated access to a page.
User posts are classic use case for POST, not PUT. You POST to the page and the information is added to the page. It does not replace the entire page as it would with PUT. POST is the right operation here.
On the other hand, there might be a few places at a site like Amazon where PUT is appropriate. For instance, some images might be stored in a static file system. If so, you’d update the image by PUTting its new representation to its known URL.
It might also be the case that you could update a page to correct an error by putting directly, and the server could work backwards to the necessary database changes. However that’s probably more trouble than it’s worth.
March 18th, 2007 at 6:55 pm
Thank you for saying that “forms don’t support PUT”. I’ve been searching the web trying to figure out why PUT is generating a GET, wondering what I was doing wrong, reading about the ‘difference’ between PUT and POST, and finding nothing.
For me, there is only a logical difference: PUT would update my web page, which would update my embedded device: POST would update my embedded device, which would update my web page. I wanted to use PUT because I wanted to see the parameters in the URI.
But that doesn’t mean that I want PUT implemented as GET. Implementing PUT as GET isn’t a disaster, but it returns data that is actually out of date: PUT or POST takes about 3 seconds to be effective.
June 6th, 2007 at 4:26 am
I don’t think there is a real use case for a separate PUT and DELETE – there is a use case for non-safe idempotent actions. The semantics of PUT/POST/DELETE often don’t cover what’s going on. It’s easy to imagine a single HTTP request resulting in the deletion of some documents, updating of some rows in some database tables and creation of some other document. The important question for me is not whether the semantics of what’s happening are best covered with PUT, POST or DELETE (that would be POST for this scenario according to RFC2616), but whether this request is idempotent or not. I’d be happy using GET for safe operations, PUT for non-safe idempotent operations and POST for non-idempotent ones and never worry about the semantic niceties.
BTW, you write “POST is used for unsafe operations” whereas the examples after it are about (non)idempotency, not (un)safeness. Pushing a button twice is OK for unsafe actions as long as they are idempotent.
July 17th, 2007 at 6:31 am
[…] http://cafe.elharo.com/web/why-rest-failed/ (“The problem is that GET, PUT, POST, and DELETE really are a minimal set. You truly do need all four, and we only have two; and I’ve never understood why. In 2006 browser vendors still don’t support PUT and DELETE. A few browsers over the years have tried to implement these as parts of editing functionality, but they’ve never allowed it in a real web application as opposed to a thick client GUI. The method of an HTML form is limited to GET and POST. PUT and DELETE are not allowed. This isn’t some failure of browser vendors to properly implement the specification either. The HTML specification only allows GET and POST as form actions. XHTML and even XForms 1.0 don’t change this. This means it’s impossible to build a fully RESTful client application inside a web browser. Consequently everyone tunnels everything through POST, and simply ignores PUT and DELETE”) […]
September 29th, 2007 at 9:32 am
Okay, simple.
PUT and DELETE have the following use: to put files and delete files (resources, but really what other resources can be PUTed and DELETEted?)
So when you upload somethign to YouTube or Amazon, you aren’t stuck with that STUPID upload box. The best upload box I know of today uses mootools and Flash, and is at http://digitarald.de/playground/uplooad.html .
Now, with today’s server security, not everyone wants to be exposing their internal uri structure to customers. YouTube might not want you to say PUT myvideo at /users/greg/coolvideo.mpghaha. However, you can still upload files to a well defined “temporary” place and then put them where they need to go. And it can be done better than with multipart post data!
Greg
March 4th, 2008 at 3:39 pm
with all this talk about REST why isn’t the most obvious implementation of REST ever mentioned, WebDAV.
It supports GET, POST, PUT and DELETE along with server side methods like COPY, MOVE, MKCOL and also gives you free metadata storage / “tagging” as well as optional versioning and locking.
WebDAV is the ulimate “RESTful” interface.
May 18th, 2008 at 4:08 am
Another take on REST: providing easily implemented access to web services via parameterized URIs, it is an aesthetic attractor for developers. Ease of implementation means reduced application complexity, and greater perceived productivity. When it comes to software development, simplicity sells; you’ll get more takers for your web service. This is not a endorsement, however, read on!
REST is particularly attractive when compared with SOAP, XML-RPC, WSDL and cousins, which have complex protocols, require relatively heavyweight clients, and need a correspondingly greater quantity of developer time. In contrast, REST brings to mind command-line data retrieval: a method name (i.e. program pathname), optionally parameterized, returning data indicated by your parameters.
However: REST has become inextricably bound to the transport of choice, HTTP. The concept of REST, that by presenting a resource identifier to a service, you’ll receive the indicated resource in return, is simple and attractive. By weaving REST out of HTTP, however, REST inherits HTTP’s limitations, as you’ve amply pointed out, ERH. By definition, any request made RESTfully must be limited to your client and server’s available set of HTTP verbs. Working around that by creating additional verbs, you’re venturing into RPC territory, the REST camp’s declared natural enemy.
If you were to develop a traditional GUI application, with internal APIs to handle the front-end’s needs, would you think to limit your choice of methods to just get(), set(), drop(), those methods provided by a particular transport’s protocol? Might you also want redraw(), clear(), zoom(), whatever’s relevant to your app’s needs? I can’t imagine any developer worth their salt would consciously design-in such limitations.
REST has its place, particularly in exposing lightweight data services to the public, but don’t constrain yourselves unnecessarily. As browser-based applications increase in complexity, you may find yourself outgrowing the limits of REST.
Here’s a gauntlet thrown down to the REST camp: Consider an Ajax page presenting lots of information; say, a stock portfolio display of 50 tickers. When the underlying Javascript code makes requests to the server, how efficient will REST be?
Will the 50 requests be sent serially, or in parallel? If serial, your user waits while the requests pass through that one-at-a-time bottleneck. If parallel, the burden is now on the server, which is now multitasking among 50 simultaneous HTTP requests. Multiply that by simultaneous users – now you’ve entered a new problem space.
Contrast with request batching, wherein the 50 requests are rolled into a single HTTP request, sent to the server. Handling parallelism is now up to your data service implementation, and not constrained to the limits of the transport. RPC is batch-friendly: a batch request is just like any other request.
To the strict REST adherents, please detail a RESTful solution.
In reality, REST and RPC live and work side-by-side. While the REST camp struggles against RPC, the rest of us will apply either (or both) as the situation requires.
May 18th, 2008 at 7:21 pm
Kevin,
the scenario you describe is trivially handleable by basic HTTP GET. I’m not sure why you think anything more is required. There’s more than on way to do it, so there are several implementation details that can be worked out in the HTTP GET, but why you think this is hard is beyond me. Do a simple GET to request the data from the server, get back an XML document, use the results to fill in the page. What’s hard about that?
August 4th, 2009 at 10:45 am
To all those wonding why PUT and DELETE are required, being RESTful is partly about having a self defining API to your system.
RESTful webapps are more like collections of database tables (resources) with triggers than they are a collection of services. The verbs mimick database verbs (CRUD).
POST = CREATE
GET = READ
PUT = UPDATE
DELETE = DELETE
If you remove PUT and DELETE, how do I update and delete? I have to overload POST and then boom, you have to explain your API.
If a webapp is RESTful, you require no documentation to immediately start using it. You operate on the resources just like database tables.
Any database that supports SQL is useable by anyone who understands SQL. Same applies to REST.
There are many other benefits to being RESTful, these benefits are brought about by being to make assumptions about the state of a system, and how it behaves in certain situations, and what responses from that system means.
You can not acheive this with SOA because ever single serivice is different (so we needs WSDL’s etc etc). As more and more RESTful sites appear, we will see better and better interoperability between these sites, resulting in large gains in productivity and innovation as sites can “mash up” with one another.
August 5th, 2009 at 5:37 pm
Nice title although “Naked Pictures” would have worked equally well and been no less misleading. How about an article on how REST is crushing SOAP in real-world use. For example, what are Amazon’s (the site) thoughts on why 85% of clients use REST despite having both SOAP and REST available? If you ask Amazonians (the river people) they will probably guess it’s simpler but equally effective, and they’d be right.
September 6th, 2009 at 11:07 am
Charlie posted: “If you remove PUT and DELETE, how do I update and delete? I have to overload POST and then boom, you have to explain your API.”
That’s a pretty good argument, but nothing about POST is self-explanatory, so unfortunately I think there is a minor flaw in the argument in that respect. As for the rest of your comment, PUT isn’t an update operation, PUT is more like CREATE… and so is POST. Comparisons to CRUD are commonplace but wrong. However, I do agree with your overall point that REST is more discoverable and self-describing, which isn’t surprising as that’s part of the stated goal.
I experimented with a REST setup that automatically mirrored XML data structures at deeper levels of the URI to match the PUT action’s defined behavior of writing an *entire* resource at a given URI. So if you wanted to change a customer’s address, but you didn’t want to re-write the entire customer record, you’d just PUT to this URI:
//site.com/customer/{customer_id}/address
There is no requirement that a resource be some unique atomic thing. A lot of developers seem to have a hard time with the idea that the URI doesn’t necessarily directly map to anything physical (like a URL does). Designing a RESTful architecture is almost like defining a language, compared to building a typical API. Kevin’s “gauntlet” challenge is a great example of how REST can quickly and easily expose a very natural-feeling solution to a problem:
//site.com/ticker/{client_id}/portfolio
There you go: a single URI that returns all fifty securities in the client’s portfolio. “One at a time” was never part of the REST concept. Better yet, if the client decides to watch a new security, you can just POST that new security back to the same URI.
Sadly, three years later the article is still relevant. The major browsers still don’t provide good support for PUT and DELETE, and even if they did, their support for security is so poor I’m not sure it would matter.
December 28th, 2009 at 10:34 am
There was a little known open source project long ago that implemented a whole slew of secure HTTP methods in Java–each with their own specific semantics–as both a client and a server at every Web point to implement Groove type collaboration (OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, NOTIFY, PUBLISH, SUBSCRIBE, FILTER, SEARCH, LOGON, LOGOFF, CREATE, SETUP, RUN, INVOKE, HISTORY, COMPLETE, TERMINATE, ESTIMATE, EXAMINE, REGISTER, UNREGISTER, COMMIT, ROLLBACK, PROXY, BROKER).[1]
It’s true you can implement everything with GET and POST, but at some point there’s no need to do yet another Web stack. The more features that get adopted and technologies that support them, e.g. pub-sub, ajax, etc, the richer the overall experience.
I agree REST is a plumbing technology, so the only thing slowing the adoption of REST is the clear value to the end user, instead of the app developer. That sounds like a good blog post….
[1] http://web.archive.org/web/20001012075129/magi.endeavors.org/html/methodology.html
June 23rd, 2010 at 9:54 am
For developers, SOAP is superior to REST. I reccomend the WCF framework, which does both.
August 23rd, 2010 at 4:25 am
[…] Why REST Failed – The Cafes […]
December 18th, 2011 at 12:18 pm
Are we safe to say that REST in its classic form of using all four methods (get,post,delete,put) is the de-facto standard today for creating web service APIs?…
Once upon time someone said that “rest failed” (http://cafe.elharo.com/web/why-rest-failed/). But then facebook implemented their API following REST quite to the dot. Other major companies like Yahoo are following is as well. I take a personal liking…
October 17th, 2012 at 4:21 pm
Using anything but POST strikes me as silly, yet another example of “ivory tower” thinking detached from reality.
POST: action=createPerson&firstName=John&id=123
POST: action=updatePerson&firstName=Jonathan&id=123
POST: action=getPerson&id=123
POST: action=deletePerson&id=123
Not only is there zero need to use anything but POST, but you can bet methods PUT and DELETE are not as well tested among webservers and application servers, and are therefore buggy.
Like everything else, common sense API naming conventions makes everything clear, and a poorly defined API will not be saved by forcing people to use GET/PUT/POST/DELETE.
October 12th, 2013 at 8:52 pm
Defining operations using http verbs is pretty silly
September 12th, 2014 at 4:30 pm
[…] The Cafes » Why REST Failed Representational State Transfer (REST) is the explicit architecture of HTTP and the World Wide Web. It is a well-designed, well thought out system that enables scalable applications that service millions of users. It is also a simpler system that enables (tags: soa REST services standards) […]