REST-*.org

Posted by Boris Lublinsky on Sep 23, 2009

Community

SOA

Topics

Web Services ,

REST

Tags

JBoss

JBoss has formally announced a new REST-* initiative during JBoss World at the beginning of the month.

REST-* is trying to clearly separate itself from WS-* by pointing the following differentiators:

WS-* is an excellent set of specifications defining various protocols and envelope formats for implementing middleware services over a network. While a vast improvement over CORBA it does suffer from a few disadvantages that the REST-* community hopes to fix, mainly:

WS-* doesn't leverage HTTP WS-* uses HTTP as a transport protocol. WS-* services mainly use HTTP as a connection setup mechanism and ignore the rich and proven features that make the Web so successful... Because we are focusing on RESTful principles the specifications put out by this organization will fully leverage the HTTP protocol and not try to re-invent its technology

WS-* has a high barrier to entry The WS-* stack is hard to implement and requires a complex stack on both the client and server to use... We hope to minimize the barrier to entry in our suite of specifications.

WS-* requires an envelope format The WS-* stack requires SOAP, an envelope format for WS-* sent message... The HTTP message format is good enough. It is simple, robust, and flexible enough.

The architectural goals of this initiative are:

Low barrier to entry Clients that use the specification should have a very low barrier to entry. They shouldn't need to install a library or large stack of software to use a specification...

Edge Cases should be Extensions Edge cases that complicate the main specification should be defined in a separate sub-specification. Extensions should strive to be layered on top of the main specification.

Pragmatic REST While a specification should strive to follow RESTful principles, simplicity should never take a back seat to being a pure RESTafarian. If you need to bend the rules of REST to create a simpler design, then that's the path that should be taken.

80/20 Rule Specifications should remain simple... Specifications should cover 80% of the most common use cases. Edge cases should not be in the main specifications...

Avoid Envelope formats Whenever possible, avoid envelope formats... Envelope formats encourage tunneling over HTTP instead of leveraging HTTP... In most cases HTTP headers should be enough to transfer metadata about the request, response, or resource.

Isolate data formats to extensions If possible, specifications should try not to define new data formats.

According to the announcement, JBoss is attempting to create a fully collaborative community, similar to JBoss.org, not something driven by vendors for vendors. They are envisioning an open source approach to:

... defining new protocols... but one of the main points about this whole effort is to document guidelines and best practices for doing things in a RESTful manner (both with and without HTTP). That might include security, management, etc.

(By the way, the above quote from Mark Little already contradicts with the architectural goals mentioned before, by hinting to both new protocols and non HTTP support).

According to Mark:

If the only thing we end up being is an aggregator for links to "standard" ways of accomplishing this or that then that's a successful outcome too... this was started: because our community wanted it. They kept running up against the same questions and lack of clear answers from various sources such as books, experts in this space and other resources. In some cases they'd get many different answers. Does that mean the answers don't exist? No. But if people who really understand REST can't agree on something then what hope is there for those who just want to go and use it? That's what REST-* is about: bringing together communities to try to come up with clear guidelines so that there's a place for everyone to go when they need those answers.

Although this new initiative is trying to stay away from REST vs WS debate:

The benefits of REST over WS-* has been debated across many articles, blogs, and public mail lists. We don't want to rehash all of it here. Please do a Google search on "REST vs. WS-*" if you want more information.

It effectively does so, by making some (not completely founded) references to WS* features. For example, it tries to say that WS* is heavy, while REST is a light-weight. Well, both standards can be implemented "by hand", in which case (assuming HTTP transport) both require about the same amount of code. On another hand, if a runtime support for automatic marshalling/unmarshalling and message routing is used, the amount of code is also about the same (for example, RestEasy - which is a very nice framework - distribution contains 38 jars). If the comparison is done for the same level of abstraction, the amount of required code is about the same. And the list goes on.

So, it comes as no surprise that the REST* announcement caused quite a few replies on Internet. Steve Jones’s post - REST-* can you please grow up - sums it up quite well:

The REST-* effort might end up documenting what already exists which indicates that part of the challenge is that lots of people don't really know what REST is and certainly struggle as they look to build higher class systems and interoperate between organizations. Part of this is of course about up-front contracts and the early vs. late validation questions. But part of it also appears to be pure snobbery and a desire to retain arcane knowledge.

He continues by stating that:

If REST really is some sword of Damocles that can cut through the integration challenges of enterprises and the world then what is the problem with documenting how it does this and having a few standards that make it much clearer how people should be developing. Most importantly so people (SAP and Oracle for instance) can create REST interfaces in a standardized way that can be simply consumed by other vendors solutions. It can decide whether WADL is required and whether Atom and AtomPub really cover all of the enterprise scenarios or at least all of the ones that count (i.e. lets not have a REST-TX to match the abomination of WS-TX).

Both REST and WS have their place in real life implementations. The issue should be not which one is better, but rather how they can coexist and when is one more appropriate. The other important thing is to make sure that comparisons are based on merits, not beliefs, no matter how strong they are. There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.

RelatedVendorContent

Free $40 SOA Demystified Book Offer

Comparing WebLogic, WebSphere, Oracle, and Open Source Application Servers

Lean development governance whitepaper by Scott Ambler and Per Kroll

JBoss versus IBM WebSphere: Cost, Performance, Efficiency, Innovation (IBM wins)

The XACML Enabled Gateway -- The entrance to a New SOA Ecosystem

Related Sponsor

Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services

1. Back to top

   Roy T. Fielding on REST-*

   Sep 24, 2009 12:38 AM by Peter Thomas

   Any article on REST-* that does not include Roy T. Fielding's comments is woefully incomplete, IMO ;)
   

   Quite frankly, this is the single dumbest attempt at one-sided "standardization" of anti-REST architecture that I have ever seen. It even manages to one-up the previous all-time-idiocy of IBM when they renamed their CORBA toolkit "Web Services" in a deliberate attempt to confuse customers into thinking they
   had something to do with the Web.

   
   
   tech.groups.yahoo.com/group/rest-discuss/messag...

   Reply

2. Back to top

   Re: Roy T. Fielding on REST-*

   Sep 24, 2009 6:33 AM by Aslak Hellesøy

   These folks don't get it. This is a huge step in the wrong direction. Like Roy said: Just close the stupid site down.

   Reply

3. Back to top

   Who can think there could ever be an equivalence between REST and WS?

   Sep 24, 2009 7:23 AM by Jean-Jacques Dubray

   <blokquote>Both REST and WS have their place in real life implementations. The issue should be not which one is better, but rather how they can coexist and when is one more appropriate. The other important thing is to make sure that comparisons are based on merits, not beliefs, no matter how strong they are. There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.</blokquote>
   

   Thank you Boris, IMHO, even Roy would benefit reflecting on your conclusion. REST or even REST-* is not and cannot be made equivalent to WS-* (and vice versa, of course).

   Reply

4. Back to top

   Re: Roy T. Fielding on REST-*

   Sep 24, 2009 8:07 AM by Boris Lublinsky

   Can we finally agree that the word "service" is as, if not more important, then "Web"

   Reply

5. Back to top

   Re: Roy T. Fielding on REST-*

   Sep 24, 2009 8:35 AM by Jim Webber

   @Boris: No. I'm afraid that would be a mistake.

   Reply

6. Back to top

   Really?

   Sep 24, 2009 9:44 AM by Ross Mason

   This seems misguided. Why screw with something good. The challenges people hit with REST is that it doesn't try and do everything, that is a good thing. The approach fits very well for many web applications but not all. Can we just help people identify when to use REST or Web Services?
   
   BTW looking at the goals (www.jboss.org/reststar/overview/goals.html) isn't that what REST has achieved already?
   
   Cheers,
   
   Ross

   Reply

7. Back to top

   Need vendor neutral organization

   Sep 24, 2009 10:47 AM by John Harby

   One aspect of WS-* that I felt made sense is that the specs were developed in some vendor neutral organizations, W3C and OASIS. This sounds like spec development by a single vendor, would Microsoft be contributing as they did in WS-*? How about Oracle?
   
   I'm not sure on the debate as to whether this makes sense at all but I would think that these types of specs should be developed in a neutral fashion.

   Reply

8. Back to top

   Re: Roy T. Fielding on REST-*

   Sep 24, 2009 11:40 AM by Alef Arendsen

   Nooooo, not yet another standards body for something so useful and elegant as REST... I'm glad Roy voiced his opinion... REST is just an interpretation of how to use HTTP in an effective way to do more than just send HTML documents across the wire. That's what it's good at and it should stay that way.
   
   OTOH, who am I, not having touched an IDE for three months ;-).

   Reply

9. Back to top

   Re: Roy T. Fielding on REST-*

   Sep 24, 2009 2:06 PM by Dilip Krishnan

   +1 :-)

   Reply

10. Back to top

    Re: Who can think there could ever be an equivalence between REST and WS?

    Sep 24, 2009 2:24 PM by Dilip Krishnan

    
    Thank you Boris, IMHO, even Roy would benefit reflecting on your conclusion. REST or even REST-* is not and cannot be made equivalent to WS-* (and vice versa, of course).

    
    Very true. On that same token, the usage characteristics of RESTful services is very different from WS-* services and REST-* may not really be suitable for the characteristics that we expect to see in the "web".
    
    

    
    There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.
    

    
    @Boris, I see your point, but I believe we should come at it from the other way. I would instead try to see if we can incorporate the goals of REST-* to the already created WS-* stack so that the whole WS-* stack can gracefully degrade to a RESTful stack given the architectural criteria.

    Reply

11. Back to top

    Re: Roy T. Fielding on REST-*

    Sep 24, 2009 2:27 PM by Dilip Krishnan

    Can we finally agree that the word "service" is as, if not more important, then "Web"

    
    
    What does this even mean? important for what and for whom?

    Reply

12. Back to top

    Re: Roy T. Fielding on REST-*

    Sep 24, 2009 3:27 PM by Boris Lublinsky

    What are we trying to do?
    Servicize or Webify our applications? Are we trying to decouple existing stovepipes or just use Web as communication protocol?

    Reply

13. Back to top

    Already widely ridiculed proposal

    Sep 25, 2009 2:59 AM by Alex Blewitt

    It seems strange that this was announced without reference to the reams of traffic that the original proposal stirred up, especially Roy's comments on the subject.
    
    In summary, it's a horrible idea, suggested by those who actually don't really grasp what REST is all about, and think that as long as you stick everything across an HTTP interface, then it's all good. But this really takes stupidity into whole new leagues; for whilst there are some who thing a GETSful architecture is in fact a RESTful one, this promises to bring the clarity and succinctness of WS-* to an otherwise sane architectural style.
    
    Not for nothing has this proposal been suggested as DIRT-*, since it's basically a way of avoiding SOAP.

    Reply

14. Back to top

    Re: Already widely ridiculed proposal

    Sep 25, 2009 9:06 AM by Mark Little

    Alex, if you look then you should find that those involved in this do "grasp what REST is all about" and Bill's approach is not to try to duplicate WS-* with REST (whether or not using HTTP). As he keeps saying, and some seem all too willing to ignore, this should be a wide community effort. So if you "grasp what REST is all about" and care enough for the wider REST audience (not just those who clearly do "grasp what REST is all about" but those who are still struggling with concepts and Q&A) to ensure that it doesn't "bring the clarify and succinctness of WS-* to an otherwise sane architectural style" then get involved. Last time I looked it was free to join and participate. I'm sure your (and others) constructive input would be greatly appreciated.

    Reply

15. Back to top

    Re: Need vendor neutral organization

    Sep 25, 2009 9:25 AM by Mark Little

    Hi John. Bill's made a few changes since the initial release of the site and blogged about them:
    
    reststar.wordpress.com/2009/09/18/were-listenin...
    
    and
    
    reststar.wordpress.com/2009/09/23/we-screwed-up...
    
    I think your point is addressed with the IETF reference.

    Reply

16. Back to top

    poor name choice

    Sep 25, 2009 10:19 AM by Kevin Williams

    The similarity between REST-* (called rest star?) and WS-* (known as W S deathstar) make me wonder if Darth Vader is behind this crap too.
    
    REST is fine the way it is, please don't f#@! with it.

    Reply

17. Back to top

    Isolate Data Formats to Extensions

    Sep 25, 2009 12:32 PM by Bill Burke

    I'm going to be fixing the language around this. What I mean by this is that to fit under the 80/20 rule, we want media types of the core specs to be very simple. Edge cases or extension protocols should be defined in new media types and link relationships.

    Reply

18. Back to top

    Re: Roy T. Fielding on REST-*

    Sep 25, 2009 12:43 PM by Bill Burke

    Believe it or not I appreciated Roy's (and other's) bluntness. I just hope these rants are more of "Get your act together!" rather than just turning your back on us. If you've read the rest-star blog You'll see we recognized our initial screw ups and that we are working to improve things on all levels: technical, website, direction, message.
    
    The point is, this was an announcement of a launch of an effort not of a final product. We're not perfect. We will make mistakes. We don't want to do this alone.

    Reply

19. Back to top

    Re: Who can think there could ever be an equivalence between REST and WS?

    Sep 25, 2009 12:50 PM by Bill Burke

    @Dilip
    

    @Boris, I see your point, but I believe we should come at it from the other way. I would instead try to see if we can incorporate the goals of REST-* to the already created WS-* stack so that the whole WS-* stack can gracefully degrade to a RESTful stack given the architectural criteria.

    
    
    What I think can be gathered from WS-* specs and open source and commercial middleware is requirements and use cases.

    Reply

20. Back to top

    Re: Need vendor neutral organization

    Sep 28, 2009 8:53 AM by John Harby

    Thanks Mark. I think this makes good sense. I also like the open source project as it allows us individuals the opportunity to participate.

    Reply

• Older >