Ian Bicking: the old part of his blog

Re: HTTP verb distaste

I don't think you can really think about a purely RESTful approach when you're using a browser since usually you can only GET or POST from the browser.

The RESTful approach is quite powerful when applied to web services (REST+Atom, look at GData for a real use case) that are meant to be used by a machine and not a human.

Other than that I personally think that:


is quite more pleasant to work with than:


for two main reasons:

  1. Easier to remember for humans
  2. Not bounded to implementation details of any sort

Regarding point n°2, the example you're providing is exposing two major implementation details:

this can provide useful information to someone who is trying to attack your site/application but even more important will force you (the developer) to keep the same scheme even if you're going to rewrite your app in another language.

Other than that I agree with Sylvain that your points regarding "the web we have now" are somewhat vague IMHO. ;-)

Comment on HTTP verb distaste
by michele


I'm gonna add something about http://www.example.com/user/{userid}

I'm changing servers as well as backend languages as we speak. It's a lot easier if the url is not bound to a particular programming language.











and eventually:


# Christopher Mahan



is easily rewritten by Apache to fit any of those others. I think you're conflating two separate issues.

# Randall Randall

That's exactly right. One additional note on the following two URLs:


I'm not sure why the examples given so far have used two different forms of the URL (i.e. /user/... and /userhome...). To really compare apples to oranges I will use these:


These two URLs exhibit the difference between positional and keyword arguments in Python. The python equivalent would be:

from www.example.com import user

Given that distinction, they really are not the same at all (although both forms may work in Python if the first parameter of the user() function happens to be named "userid"). While some may argue that the first form is more "REST-ful", I would say simply that they are not the same and cannot be compared that way. The first form derives the meaning of the parameter from its position within the URL. In contrast, the second derives the meaning of the parameter from its explicit name.

There is one gotcha here though: conventionally "keyword arguments" are ignored by web servers if they are not "needed" by the server/script. This has the implication of making a set of textually unique URLs resolve to a single resource. For example:


Depending on the implementation of the "user" page/script, these two URLs may or may not refer to the same resource. This may be viewed as either a benefit or a disadvantage in the implementation of HTTP servers. Of course the same thing could happen with "positional" arguments in HTTP. Given a sufficiently flexible (or ill-configured) server, the following two URLs may refer to the same resource as well (although it would violate convention):


I would argue that the thing that needs to change is the ability of web servers to easily map arbitrary URLs to arbitrary resources. The structure of directories and files on a server is an outdated and constrained model. Even more outdated and outrageous is the use of file extensions to determine resource types. ModRewrite is a poor solution because it is far too complicated to configure for novice users. It's like trying to use a jackhammer to pound a finish nail--its nearly impossible to determine what it will hit unless you're well exercised in the art of regular expressions and other various criptic configuration giberish.

# Daniel