Designing a RESTful Web Application

RESTFUL Web apps are great if you want cookie cutter and just a simple service (done some myself).

But more trouble than they are worth if you want fairly custom url schemes and are doing something a bit more useful then just plain old CRUD.

another nit: GET requests are idempotent, but that's a necessary, not sufficient, condition. You should just say they have no side effects.

"For example, if you want to add the ability to create an article, it might be tempting to create a URI called /create_article/. This is wrong, because it conflates the object (the resource) and the action (creation)."

So what URL do I use if I want to search articles? What if I want to approve articles? The simple CRUD perspective has fallen apart for me pretty quickly in practice- I need more than 6 verbs (adding HTTP OPTIONS and HEAD in there). I think HATEOAS is a pretty good approach, but there still seems to be a lot of noun-ification going on in RESTful apps just to stick with the style. (e.g, PUT //article/1234/approval used when disapproving an article)

I've always thought that the URL to use when searching articles is the same you would use when retrieving a collection of articles, just with the search terms or filters included as parameters, ie, /articles?q=terms

Approving articles could be as simple as posting TRUE to the "approved" attribute of an article, ie, /articles/1234/approved

You just need to make sure that every resource that can be modified or retrieved has a URL.

I'm thinking of forwarding this link to my boss, so that he can get a quick tour of REST :) Thanks!