I'am planning to build RESTfull API but there are some architectural questions that are creating some problems in my head. Adding backend bussiness logic to clients is option that I would like to avoid since updating multiple client platforms is hard to maintain in real time when bussiness logic can rapidly change.

Lets say we have article as a resource ( api/article ), how should we implement actions like publish, unpublish,activate or deactivate and so on but to try to keep it as simple as possible?

1) Should we use api/article/{id}/{action} since a lot of backend logic can happen there like pushing to remote locations or change of multiple properties. Probably the hardest thing here is that we need to send all article data back to API for updating and multiuser work could not be implemented. For instance editor could send 5 seconds older data and overwrite fix that some other journalist just did 2 seconds ago and there is no way that I could explain to clients this since those publishing an article is really not in any way connected to updating the content.

2) Creating new resource can also be an option, api/article-{action}/id , but then returned resource would not be article-{action} but article which I'am not sure if this is proper. Also in server side code article class is handling actuall work on both resource and I'm not sure if this goes against RESTfull thinking

Any suggestions are welcomed..