Nobody Understands REST or HTTP

1) HTML isn't English, it just has some similar sounding tokens. You can't assume the semantics are the same.

2) Well, there's HTTP and there's REST, they're related but no the same. HTTP is a full protocol, completely defined; you can't add more verbs, period.

REST is an architectural style. It has a series of constraints, and it tells you that if your system architecture complies to them, it'll have some useful properties, like low coupling and such. HTTP is just an example of a RESTful architecture.

Now, if you're designing an architecture and you want to follow REST, you can choose the verbs you want, but these should be generalist and not tied to specific names. This provides an Uniform Interface, which simplifies and decouples the the architecture.

3) See above. HTTP statuses are fixed, you can't return other stuff. If you're designing your own architecture, you can use whatever you want. Hell, you can return different pictures of kitties for each status if you want to.

4) As the Zen of Python states, practicality beats purity. But you should be aware that by adding state to the connection, you'll lose some advantages. Let's say the user is performing a multiple step action, and the server he's using breaks. If the server was holding the state, now the user has lost all the work and he'll be pissed at you. If on the other hand, the state was saved by either the client, or more "RESTfully", by the mere fact that he was on a specific URL, than any other server can pick up where the other left without annoying the user.

5) Sure. We just need to rewrite all the browsers and servers worldwide, including a bunch of embedded ones that can't be reflashed. It's possible...

But to access that JSON document with the URI, you had to know the URI already (in this case, by following the Location header).

It's like having a link on a webpage to itself, what's the point? I can just refresh.

It really is a good read, I need to digest it, but my initial reaction is that some of this isn't pragmatic. Versions in URLs makes for dead-simple routing in any framework. Also, many APIs are used in a way where you know consumers will create a resource without requesting it (or at least, not within the same session). So why return any location information (whether in a header or in the body)?

Rest was a really big deal in the Java web-app world for about a year...

It was back when early versions of Struts were 'the designated alternative', and in the bad old days of J2EE and JAX-RPC.

Then Java EE 5 came out, which solved large chunks of the pain that J2EE inflicted, JAX-RPC got replaced with the infinitely better JAX-WS and there was a new breed of web frameworks as well, which blew Struts out of the water.

About that time REST essentially became 'yesterdays technology, solving yesterdays problems'.

I find it interesting that the guy banging the REST drum is a Ruby fan. Has REST always been part of Rails? Or is it something that has crept in over the last couple of years?

Is there anything genuinely new here, or is it the same old story, some dude clinging desperately to an obsolete technology?

First off, thanks for taking the time to reply to my admittedly baiting post. I do have a serious point I'm making though. Lets walk through it.

http://www.mywebsite.com/api/getAllPageNames/returnType/JSON

In this string 'get' appears once. However, as an experienced dev, you know that this is a GET request. To you it looks redundant. However to someone trying to understand what will happen when they hit enter with this URL in their location bar it is meaningful.

The question at that point is naturally "But if you don't know that's a GET request then why are you using an API?"

This is the point I'm driving at. There are scores of underserved individuals who want to do interesting things with your website that go beyond your GUI, and they are just brave enough to read through your API docs.

Now, when I'm thinking about API design I have a big initial choice. Is this API for skilled developers who care about the REST spec? Or is this a tool for as many people as possible to get more out of my service than I have time to accommodate with features. This is where I will always say "I don't care about the spec." A really talented dev will read the docs, discover how my design works, and will write something cool on top of it. I can trust the hackers I know to make things work by hook or by crook. The same cannot be said for someone who really wants to extend my functionality but isn't a talented developer.

I feel it's my responsibility to produce a tool that can be used by as many people as possible. I don't want to make a high-end professional camera, I want to make a better point and shoot. I want to extend the abilities of people, not demand they gain a large skillset to use my new tool.

New programmers and enthusiastic users are always on my mind. These are the people who's preconceptions are that it should 'just work' and that if it doesn't it's my fault.

This is why I applaud decisions like Chrome dropping http:// It simply doesn't matter to 99% of the users of the product, and in fact makes browsers less friendly and more confusing.

If I can get my api to work like this, then I will:

'I want to see all the names of pages on mywebsite.com'

If I had access to a deterministic natural language parser then I'd use it. As such a thing doesn't yet exist, I try to remain as true to that ideal as possible.

The REST architecture may be less confusing than others, but it is far from simple.