[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] REST vs. HTTP in the real world



John Elliot wrote:
I'm done. I've poured hours into this discussion now, and I really don't have anything additional to contribute. I've made my points about PUT and DELETE, and I've made sense to some people. I'm happy about that.


What was the point, John? I think you already had the outcome in mind, complete with abuse for people with alternative viewpoints...


Ultimately, HTTP was designed in a "hypermedia" era, with largely static content. Over 15 years we've managed to bolt on a whole bunch of things to make it do what we want, including "web services". The result is that people "do what works" - most people get by with GET and POST and see no need for anything else. As a result, you will probably find very few systems support anything else (one of the Google articles linked in the discussion stated that "DELETE" may not work past some "firewalls", so they are obviously not RFC compliant).

The only reason you seem to be arguing that you should consider PUT or DELETE at all is because of keeping with the original semantics of HTTP and REST. As mentioned by others there are some benefits in terms of cachability, as designed into HTTP, and one of the apparent tenets of REST. But cacheability is only of benefit for immutable data in HTTP - all changes have to get sent back upstream with the intermediate caches/proxies invalidated.

I vaguely remember using PUT for file uploads at one point, but you can do the same with POST. Some Content Management Systems may use PUT and DELETE for uploading though, for "file-oriented" resources. So in terms of current "web 1.0" applications, there is little fundamental need.

In terms of "web services", things are a little different, since you have greater control over the client or browser. But I would argue that existing approaches to managing the exchange of data in a distributed fashion are largely inadequate and likely to be superseded in 5 years. JSON is fairly insecure, so I would be enforcing a lot of additional input and output validation if I were to go down that path. (I assume people are using JSON as an light-weight, asynchronous alternative to fully blown SOAP which is too heavy-weight and RPC-oriented)

Cheers,

Nigel

-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx
If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.