A while ago I wrote a "web service" of sorts that seems to be something like what's described in the article. It consisted of a cgi script that when asked to do stuff, did it, and returned plain text (Content-type: text/plain). URLs looked like: https://.../foo.pl?do=something&arg1=bar&arg2=baz ('...' replaced by the actual domain). If you asked it for a list of something, results were returned as one item per line. If you asked it to *do* something, it usually returned "OK" or "ERROR".
So, that's all there was. Everything was a GET, the base URL was always the same (just a path to the cgi script, and no equals sign in the path or anything like that), and it was only really used by a dedicated client app -- though you could access it from a browser too, if you cared to (mostly for testing purposes). The client provided the user interface and talked to the cgi script behind the scenes.
Was my method inferior? Everything worked like it was supposed to. In what ways is official "REST" better?
| [reply] |
Just like Eddie told Frank it's *words AND music* ... for REST, it's *verb AND name*. You could write a doctoral dissertation about it (ha!) but basically REST is all about having the right name (URL) for your resource and then using the right verb (HTTP's PUT, GET, POST, DELETE) to operate on it. Lot's of folks see those verbs and map it to the database world of CRUD (Create, Retrieve, Update, Delete).
So the RESTafarians would note that you overcomplicated your app by placing the verb where just the name should and by overloading GET so that it updates the resource -- GET's should be idempotent - just retrieve the resource as it is - do not modify it.
That all being said, I cannot tell if your method is inferior or not. Did it work? Did it meet the requirements? If so, who's to say your way was inferior. But it sounds like your app was more of a browser-to-server app, when people talk about REST (and/or SOAP), it's rare that they mean browser-to-server interaction but server-to-server interaction.
| [reply] |
Did it work? Did it meet the requirements?
Yes.
But it sounds like your app was more of a browser-to-server app, when people talk about REST (and/or SOAP), it's rare that they mean browser-to-server interaction but server-to-server interaction.
Thanks for the insights.
In my case, the interaction was custom_client-to-server. It was only browser-to-server if you wanted to try it out manually by typing in the URL. Not sure exactly what you mean by server-to-server... My webapp didn't care if you were acessing it from a desktop app, from a flash app in a browser, a terminal-based client running anywhere, or from another webapp.
| [reply] |