Automated interactions in REST

Mark Baker and Savas are discussing service description. Mark suggests that its better for the interface and description to be dynamically negotiated. Is this workable in practice, or just ivory tower? Mark Baker on automated interactions:

Hold on. Why would they ever do that? Why would they want to artificially restrict the type of documents returned from an interaction? That would mean that if they wanted to insert a step between order submission and and song download, that they’d have to change the interface and its description? No thanks. I would prefer that the client determine what to do based on the type of the document that actually arrives. Let’s keep the perpetually-static stuff in the protocol, and let everything else happen dynamically.

I follow this for human interactions. I submit my order form, and where yesterday iTunes began downloading my song, today it returns another HTML page. I look at the page and see a form, which I dutifully fill out and submit, after which my song begins to download. No problem. I was able to adapt.

But on what basis can we expect an automated interaction to adapt? How do we prevent “extra steps” from breaking client automatons?

Comments are closed.