Anthony Goubard REST vs REST
REST is becoming the buzz word of this year. After spending 4 years developing an open-source REST web services framework you might think I should be pleased. Well, not that much.
Actually you have 2 REST that I would call the Pure REST and the RESTfull way. The pure REST is the REST were the web services is resource based using the HTTP verbs (POST, GET, PUT, DETELE) to manage the resources. Parameters are in the URL path. This one is back up by JSR 311 e.g. HTTP DELETE http://www.mysite.com/service/15002/
The RESTfull way is where request are done with GET and POST and parameters are in the URL query. This one is back up by Axis or Yahoo! API.
I largely support the RESTfull way
Here are the pure REST problems:
- The way we think of web services is not resource based.
- There is no details on how to handle optional parameters.
- There is no details on how to get the specification of the web service.
- There is no details on how to assign types and contrainst to your parameters.
- It not easy to tests (except for GET).
Does that mean that the RESTfull way can't cache? No but then you need to do it (or specify it) based on the service called.
I've seen at presentations and also saw some discussion on the net and every time they have to name examples they come with the Yahoo REST api which actually uses the RESTfull way.
PS: In XINS there is also one of the demo which is pure REST but pure REST is not the default protocol.
- Login or register to post comments
- 7380 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Will Hartung replied on Sat, 2008/07/12 - 1:05pm
Well, there's your fundamental problem.
Let me rephrase that for you.
"Since I don't get REST, it's square peg doesn't find in the round hole of my world view."
Amazing that.
REST is like SOA. It's an idiom. A design philosophy. Like Object Oriented. Just like you don't need SOAP Web Services to do a SOA architecture, you don't need HTTP to have a REST based design. Perhaps you'd like to access you database through db://mysqlhost:1234/customers/123.
What protocol is that? Why it's the db protocol. Says so in the URI. What's the db protocol? It's obviously an internal protocol. We don't even know what the format is. We DO know, however, that we can access that resource using some limited set of verbs to manipulate the resource. Those verbs are also application specific. Most likely, they'll be common verbs (like GET, PUT, DELETE), why break tradition. But they don't have to be. There's no rule telling you what the verbs are.
RESTful design JUST HAPPENS to work well with the HTTP protocol, but it's hardly a requirement. Thus the confusion.
You may as well be complaining that JMS is a lousy at RPC. Of course it is! It's an asynchronous messaging framework, completely different architecture.
What you call "RESTful" I call "ad hoc RPC over HTTP". There's nothing "REST" about it.