Comments like 'you are doing it wrong', and 'you haven't understood REST' are posted to most REST articles I have seen. Obviously nobody ever has done REST right.

Or the people that understand REST don't write about it.

I've found a painful lack of examples too. There's a lot of written material but few concrete examples from what I've found...

Just wait until you see my Lean startup's REST based MVP that we produced with Agile.

(Downvotes, ho!)

I've been reading a lot of these articles and would like to think that I've implemented a RESTful API. I use GET for the get_all, get_one methods; PUT for create and PUT for replace/modify (as in replacing a field, not appending to it), HEAD for checking if certain resources exist, and DELETE for the obvious.

The framework I'm using assigns any visit a new session, but it's unused in the sense that the REST interaction doesn't require the session and also doesn't use it - authentication is handled using a the "Authorization: basic" header.

Well I've created what I believe to be, and what this article describes twice now for internal web-services[1]. Its really quite easy if you are disciplined and it really ends up being a very nice interface. The trick becomes if you want to eat your own dogfood with a website. Since forms can only post and get it makes it tricky without JS.

Otherwise I've been very happy and content with my 100%[1] restful webservices.

[1] According to this article, the one it linked to, and a medium skimming of the original dissertation.

Are you just HTTP-compliant (using the proper verbs and having Uniform Resource Locations point to actual resources) or are you truly 100% restful?

I suppose looking back I do have a concept of a session which is state. So no, but I organized my verbs and URL's to meet the specification and have the option to remove those sessions.

But I guess since I'm using a cookie-based sessions its less of an issue for state changes since the state stays mostly on the client.

Agreed. Sessions and the limitations of forms are the biggest obstacles to 100% restful APIs used from web browsers.

You can however use XHR form submission[1] in the background (which is a good practice (better site responsiveness) after all) to use HTTP methods other than GET and POST.

[1] e.g. http://jquery.malsup.com/form/#json

I probably should have specified "other than atom pub". It is so trivially REST since it simply describes publishing web pages using HTTP.

I'm more interested if anyone has managed to use REST for an API that has more business logic than simply publishing documents.

I don't understand the distinction you're making between "trivially" and "non-trivially". Looking at pretty much any commercial CMS you can see that publishing documents can involve all kinds of business logic.

rest is how the web works.

if you used a browser to write that comment, I would say rest is working pretty well.

From you're massively oversimplified statement I can only conclude you don't understand REST. HTTP != REST. REST is how the architects of HTTP generally expected things to work, but due to tunneling, and other approaches to API design it, generally speaking, most systems that operate over HTTP don't actually work that way.

In fact I'd be willing to bet this comment form isn't all that RESTful.