What does using RESTful URLs buy me?

问题:

I've been reading up on REST, and I'm trying to figure out what the advantages to using it are. Specifically, what is the advantage to REST-style URLs that make them worth implementing over a more typical GET request with a query string?

Why is this URL:

    http://www.parts-depot.com/parts/getPart?id=00345

Considered inferior to this?

    http://www.parts-depot.com/parts/00345

In the above examples (taken from here) the second URL is indeed more elegant looking and concise. But it comes at a cost... the first URL is pretty easy to implement in any web language, out of the box. The second requires additional code and/or server configuration to parse out values, as well as additional documentation and time spent explaining the system to junior programmers and justifying it to peers.

So, my question is, aside from the pleasure of having URLs that look cool, what advantages do RESTful URLs gain for me that would make using them worth the cost of implementation?

回答1:

The hope is that if you make your URL refer to a noun then there is a better chance that you will implement the HTTP verbs correctly. Beyond that there is absolutely no advantage of one URL versus another.

The reality is that the contents of an URL are completely irrelevant to a RESTful system. It is simply an identifier.

It's not what it looks like, it is what you do with it that is important.

回答2:

One way of looking at REST:

http://tomayko.com/writings/rest-to-my-wife (which has now been taken down, sadly, but can still be see on web.archive.org)

So anyway, HTTP—this protocol Fielding and his friends created—is all about applying verbs to nouns. For instance, when you go to a web page, the browser does an HTTP GET on the URL you type in and back comes a web page.

...

Instead, the large majority are busy writing layers of complex specifications for doing this stuff in a different way that isn’t nearly as useful or eloquent. Nouns aren’t universal and verbs aren’t polymorphic. We’re throwing out decades of real field usage and proven technique and starting over with something that looks a lot like other systems that have failed in the past. We’re using HTTP but only because it helps us talk to our network and security people less. We’re trading simplicity for flashy tools and wizards.

回答3:

One thing that jumps out at me (nice question by the way) is what they describe. The first describes an operation (getPart), the second describes a resource (part 00345).

Also, maybe you couldn't use other HTTP verbs with the first - you'd need a new method for putPart, for example. The second can be reused with different verbs (like PUT, DELETE, POST) to 'manipulate' the resource? I suppose you're also kinda saying GET twice - once with the verb, again in the method, so the second is more consistent with the intent of the HTTP protocol?

回答4:

One that I always like as a savvy web-user, but certainly shouldn't be used as a guiding principle for when to use such a URL scheme is that those types of URLs are "hackable". In particular for things like blogs where I can just edit a date or a page number within a URL instead of having to find where the "next page" button is.

回答5:

The biggest advantage of REST IMO is that it allows a clean way to use the HTTP Verbs (which are the most important on REST services). Actually, using REST means you are using the HTTP protocol and its verbs.

Using your urls, and imagining you want to post a "part", instead of getting it

First case should be like this:

You are using a GET where you should have used a post

http://www.parts-depot.com/parts/postPart?param1=lalala&param2=lelele&param3=lilili

While on a REST context, it should be

http://www.parts-depot.com/parts

and on the body, (for example) a xml like this

<part>
   <param1>lalala<param1>
   <param2>lelele<param1>
   <param3>lilili<param1>
</part>

回答6:

URI semantics are defined by RFC 2396. The extracts particularly pertinent to this question are 3.3. "Path Component":

The path component contains data, specific to the authority (or the scheme if there is no authority component), identifying the resource within the scope of that scheme and authority.

And 3.4 "Query Component":

The query component is a string of information to be interpreted by the resource.

Note that the query component is not part of the resource identifier, it is merely information to be interpreted by the resource.

As such, the resource being identified by your first example is actually just /parts/getPart. If your intention is that the URL should identify one specific part resource then the first example does not do that, whereas the second one (/parts/00345) does.

So the 'advantage' of the second style of URL is that it is semantically correct, whereas the first one is not.

回答7:

"The second requires additional code and/or server configuration to parse out values,"

Really? You choose a poor framework, then. My experience is that the RESTful version is exactly the same amount of code. Maybe I just lucked into a cool framework.

"as well as additional documentation and time spent explaining the system to junior programmers"

Only once. After they get it, you shouldn't have to explain it again.

"and justifying it to peers."

Only once. After they get it, you shouldn't have to explain it again.

回答8:

Don't use query/search parts in URLs which aren't queries or searches, if you do that - according to the URL spec - you are likely implying something about that resource that you don't really want to.

Use query parts for resources that are a subset of some bigger resource - pagination is a good example of where this could be applied.