After reading this URL, I long for a Linus anti-REST email | Hacker News Reader

After reading this URL, I long for a Linus anti-REST email

git.kernel.org

5 pointsrortian15 comments

After reading your title, I'd love to hear what you think REST is.

I'm only just starting on reading O'Reilly's "RESTful Web Services" (Richardson & Ruby), and I've but skimmed the Felding dissertation, but the URI doesn't strike me as particularly RESTful.

In particular, custom verbs are embedded within the querystring (a=blob, a=blob_plain, a=history, a=tree, etc.) rather than relying solely on HTTP verbs and varying the base URI.

And that base URI never changes: it's always http://git.kernel.org/, regardless of what resource is being requested.

If I can't determine what resource I'm requesting from the base URI alone, how can it still be considered RESTful and not an RPC-style or hybrid architecture?

I personally think you can learn everything you need to know by reading ch8 and on. the appendices are a great HTTP reference. seriously though the book seems to rehash the same stuff over and over, ch8 is more of a summary of that same stuff.

"base" URI may consist of host+port+path not _just_ host or host+port. you don't have to switch subdomains or hosts in order to provide RESTful interfaces.

But the git web UI doesn't have a path component. As far as I can tell, it's always just '/' with a huge querystring on the end.

it's a client to the restful interface... web browsers current suck at restful interfaces because forms don't support all the http methods, and you can use your own image for a button (or other form element).

I guess I associate having cleaner URLs with REST. It's just funny to me this URL just passes params.

clean uris are orthogonal to REST. They're nice to have, but you could have randomly generated strings of alphanumericals as resource identifiers and still be perfectly RESTful.

Yeah I guess that is true. I wish I knew a better term for what I'm getting at.

How do you suggest associating URLs to nodes in a revision control history in a "clean" way? The URL linked in this post doesn’t seem exceptionally unreasonable given the content it points at. It uses a URL query string in a similar way to countless other mainstream web resources.

How does that have anything to do with REST?

Incidentally, if you want, you can shorten your URL quite a bit (from 182 to 107 characters). As in the use of git from the command line, your hashes only have to be long enough to be unique. So this goes to the same place:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...

If you want an even shorter URL (73 characters), you can drop the hb and f arguments, though that provides a bit reduced functionality (just the content):

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...

You’re probably right that it could/should intelligently fill in the path, and not require that as an explicit argument. The a=blob argument seems to be unnecessary so could likely be dropped altogether. But eh.

I think github makes a good crack at it

http://github.com/rortian/Retinex/blob/53a2f818ce301f4912b02...

But, you're right I was wrong to say anything about REST. I just thought it was an interest way to do a git tree explorer.

I'm sure it's not desirable to come up with a minimal character URL for this sort of thing, but I hard to see either approach as suboptimal.

So you like slashes between unlabeled arguments instead of key=value pairs separated by semicolons? I don’t see how the slashes have any particular advantage, given that the URLs are much too long to be remembered or easily read aloud, etc., either way.

Totally depends on the context. I see no reason to have a priori preference for either. This way of doing it somehow felt counter to what feels like the trend for a lot of sites.

When I'm messing with my own site, I prefer to do key value pairs, so I can easily see what I'm messing with.

I do like having some things with a rails/route type url mapping. Tends to allow for much more simplified code.

I don't see any problem with it. URL or URI should be opaque to their users by definition. in a properly designed and implemented REST interface you are never required to construct urls, you are just supposed to extract them from responses. As long as URL uniquely identifies a particular "resource" and as long as you properly use the HTTP verb and 'accept hearer' semantics, how the actual urls look like doesn't matter at all

How about:

http://bit.ly/crIS4n

Reply on news.ycombinator.com