1,2,3) Strictly, they are all resources. A "Clean" resource can be created (POST|PUT) describing what to clean. It will create (201) that resource which you can

1,2,3) Strictly, they are all resources. A "Clean" resource can be created (POST|PUT) describing what to clean. It will create (201) that resource which you can read (get the status), even delete (cancel the action), or change (POST/PUT) again. Take a look at the http://restcookbook.com/Resources/asynchroneous-operations/ http://restcookbook.com/Resources/asynchroneous-operations/, which basically describes this. 4) According to Roy Fielding, you don't (you don't version your website), but you can add/change/delete your resource versioning. I'd (and many) prefer the accept-header for this, but there are as many different versioning systems as there are API's. 5: hypermedia / HATEOAS 6: sure. If it makes sense. Not everything is hierarchical, but things that are, do it. 7: 418 The reason for this was figure out myself how certain things should be done in a "restful" way. To be honest, truly restful is an utopia imho, but on a daily basis, I see many advantages (as well explained in Roy fieldings dissertation) about the restful setup in comparision to a non-rest setup. Pragmatically, since I'm not building API's for HUGE system (and even if they are or will become so), it's still possible to use non-rest components (yes, even verb-like systems and url versioning like /api/v1/. I consider rest to be like the pirates code: not so much a strict law, but more as a guideline.