Oh how I wish SOA topics had the single, authoritative source that REST enjoys. Simply awesome.
This part caught my eye as it matches an interaction approach that makes a lot of sense to me: > Personally, I would just use POST for that button. The API can > compensate for the use of POST by responding with the statement > that the client should refresh its representation of the larger > resource state. In other words, I would return a 303 response that > redirected back to the VM status, so that the client would know > that the state has changed. The post-redirect-get (PRG) pattern is described at http://www.theserverside.com/patterns/thread.tss?thread_id=20936. I'm not sure if Jouravlev coined the name but the concept is quite useful. The principle behind it is simple: * Keep update operations separate from view operations. The resulting rule of thumb is that the result of a post should be a redirect to a get. This allows a browser user to freely move back and forward at will (as good web apps should) and simplifies the server side of things since "change state" and "return state" code is kept separate. -Rob
