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