Anthony Goubard is a freelance Senior Software Engineer from Amsterdam. He has developed in Java since 1995. He has developed many softwares available at and is the main developer of the Web Services framework XINS. Anthony is a DZone MVB and is not an employee of DZone and has posted 33 posts at DZone. You can read more from them at their website. View Full User Profile


  • submit to reddit

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

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).
The only advantage named is the possibility to cache GET request as you know it won't change any data. I think that this argument is defining the architecture based on premature optimization.

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.


Published at DZone with permission of Anthony Goubard, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Will Hartung replied on Sat, 2008/07/12 - 1:05pm

Here are the pure REST problems:
  • The way we think of web services is not resource based.

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.