Discussions

News: Publishing a RESTful Web Service with JAX-WS

  1. Publishing a RESTful Web Service with JAX-WS (13 messages)

    Doug Kohlert has written "Publishing a RESTful Web Service with JAX-WS," focusing on the JWSDP 2.0 release.

    It's a very simple example (adding two numbers and returning the result), and it's rather unusual to see REST used in this manner – but it's also instructive to see how REST can be implemented within the JAX-WS framework, with annotations and resource management.

    The example is better suited to XML-RPC or SOAP, as the actual invocation would look something like "http://192.168.2.10:8080/addnumbers/num1/10/num2/20" to get a result of "30," and one would have hoped for a more traditional application of REST. There's also quite a bit of code involved in pulling out the parameters, which indicates that perhaps REST isn't aligned well within JAX-WS yet.

    Do you think the example shows that REST in JAX-WS is clean enough to use in real-world code? If not, how would you like to see REST handled?

    Threaded Messages (13)

  2. The example is better suited to XML-RPC or SOAP, as the actual invocation would look something like "http://192.168.2.10:8080/addnumbers/num1/10/num2/20" to get a result of "30," and one would have hoped for a more traditional application of REST. There's also quite a bit of code involved in pulling out the parameters, which indicates that perhaps REST isn't aligned well within JAX-WS yet.Do you think the example shows that REST in JAX-WS is clean enough to use in real-world code? If not, how would you like to see REST handled?

    I remember writing simple REST services in Perl years ago, which included just envoking a URL with parameters.

    So basically the above would looke more like...

    http://192.168.2.10:8080/addnumbers?num1=10&num2=20

    I'm trying to figure out the reason for making thins so complex by embedding parameters within the URL?, where the standard URL envokation already dictates how to pass QUERY STRING parameters.

    ILya
  3. I remember writing simple REST services in Perl years ago, which included just envoking a URL with parameters.So basically the above would looke more like...http://192.168.2.10:8080/addnumbers?num1=10&num2=20I'm trying to figure out the reason for making thins so complex by embedding parameters within the URL?, where the standard URL envokation already dictates how to pass QUERY STRING parameters.Ilya

    Well, it would of helped if I read the article in detail. I guess he did provide both ways for envoking the URL, though I'm not sure how and why the first one would be used.

    Ilya
  4. I read the article and the posts here. Am I missing something? REST does not require that you pass your parameters either in the URL, a query string or HTTP parameters. You can also use HTML or XML. In other words, you can fill out a form (HTML form, XForm) or an XML document and send it to the URL representing the service. The service then responds with HTML or XML containing a response.

    It seems to me that all these methods are "RESTful" and any of them are valid approaches for some services. All of them combined are probably sufficient for 80% of the external services you may need to write.
  5. William,

    You are right but not specific :) All these methods can be (not necessarily are, but can be) RESTful.

    You are however, 100% right that REST does not mandate to pass arguments via query string.

    From Wikipedia:
    Representational State Transfer (REST) is an architectural style for distributed hypermedia systems like the world wide web. The term originated in a 2000 doctoral dissertation about the web written by Roy Fielding, one of the principal authors of the HTTP protocol specification, and has quickly passed into widespread use in the networking community.

    While REST originally referred to a collection of architectural principles (described below), people now often use the term in a looser sense to describe any simple web-based interface that uses XML and HTTP without the extra abstractions of MEP-based approaches like the web services SOAP protocol. Strictly speaking, it is possible (though not common) to design web service systems in accordance with Fielding's REST architectural style, and it is possible to design simple XML+HTTP interfaces in accordance with the RPC style, so these two different uses of REST cause some confusion in technical discussions.

    Systems that follow Fielding's REST principles are often referred to as RESTful; REST's most zealous advocates call themselves RESTafarians.

    And a good explanation of REST vs RPC:
    http://en.wikipedia.org/wiki/REST#REST_versus_RPC
  6. REST styles[ Go to top ]

    I think REST now takes the forms of "pure" and "applied".

    Pure REST inteprets a URL as a single resource or resource collection. Query parameters would only be used when GETting from a collection. All HTTP methods are allowed, not just GET & POST.

    Applied REST views URLS as just service endpoints, usually only available via GET & POST.

    The problem I have seen is that there are many projects publishing examples of using their particular technology to implement a RESTful service, yet because they all interpret URLs/parameters in different ways, it would be impossible to write a generic client, a big minus when comparing with SOAP.

    Kit
  7. REST styles[ Go to top ]

    I don't agree. What you describe as "pure REST" is RESTful, but what you describe as "applied REST" is not RESTful, it is just "using HTTP".
    The problem I have seen is that there are many projects publishing examples of using their particular technology to implement a RESTful service, yet because they all interpret URLs/parameters in different ways, it would be impossible to write a generic client, a big minus when comparing with SOAP.Kit

    Generic client? Impossible? Sorry, but isn't my Web browser a generic client for traversing a REST system?

    A URL is a unique string. It does not contain any meaning, it is just a unique string refering to a resource. http://example.org/wooyayhoopla could reference my a resource representing my toaster just as easily as http://example.org/mytoaster could. Any perceived meaning in a URL is purely that, perceived.

    REST says nothing about the format of URLs because we don't care about the format of URLs, they contain no meaning other than that they reference a resource. The meaning is added by the resource representation that uses the URL in a link or a forms language.

    For example, TheServerSide.com news page has links to articles, these articles have totally random (afaic) URLs, but I don't need to know what they are since the news page links to them.

    There is no difference between this and a "Web service" that returns some format of pure data, remember the fourth principle of REST (http://en.wikipedia.org/wiki/REST#Principles), "hypermedia as the engine of application state".
  8. REST styles[ Go to top ]

    I don't agree. What you describe as "pure REST" is RESTful, but what you describe as "applied REST" is not RESTful, it is just "using HTTP".
    Exactly. Sorry, this was the point I was making and I didn't make the irony obvious. "Applied REST" has taken on the mantle of REST but is not REST (ie. pure REST). But there are many frameworks claiming to be "RESTful" which are "just using HTTP".

    And they all give special meaning to the format of their URLs, contrary to pure REST as you say. And as a result they make writing a generic REST client impossible.

    Kit
  9. XINS and REST-RPC[ Go to top ]

    The problem I have seen is that there are many projects publishing examples of using their particular technology to implement a RESTful service, yet because they all interpret URLs/parameters in different ways, it would be impossible to write a generic client, a big minus when comparing with SOAP.Kit

    XINS is another technology having it's own approach to HTTP calls. It supports GET, POST and HEAD.

    In order to standardize and have an REST/POX-style alternative to complex standards such as SOAP, we're extracting the protocol and sticking it into a specification. We're currently calling is "REST-RPC". A FAQ is available:
    http://xins.sourceforge.net/restrpc.html

    Input would be appreciated. Is there a market for such a "standard" ?
  10. pretty silly[ Go to top ]

    Can I just point out how silly it is to be using a framework for this sort of thing.

    (maybe we should use a framework for the part where we actually add the two numbers together. Or at the very least we ought to be using BigInteger. Wait a minute, how do we know *for certain* that the numbers are integers? They could be arbitrary precision floats. We should use BigDecimal? So now it's obvious that we need a framework to handle the adding of the two numbers together, because otherwise it's not generalized enough, and might not handle every imaginable possibility.

    you get it?


    -geoff
  11. pretty silly[ Go to top ]

    Sure, you can mention that.

    I could mention how ridiculously silly it is to write "Hello World!" in a new programming language all the time. I mean, who the heck needs an application to put some text on the screen that just says "Hello World!". For that matter who the heck needs a Pet Store web application anyway!?!?

    This is obviously a simple tutorial/proof of concept. In those situations it is PREFERRED that one use a very simple problem. That way your audience can focus on the important part and not get lost in a complex example.
  12. pretty silly[ Go to top ]

    Actually, I think Geoff has a point. So far as I can tell from the example, RESTful JAX-WS is more complicated then just banging out a servlet to do the same thing.

    Does anyone know what advantages does JAX-WS provide over just writing a servlet?
  13. pretty silly[ Go to top ]

    Actually, I think Geoff has a point. So far as I can tell from the example, RESTful JAX-WS is more complicated then just banging out a servlet to do the same thing.Does anyone know what advantages does JAX-WS provide over just writing a servlet?

    Yes, frameworks are here to provide us a generic (maintenance friendly) way to accomplish things. Although Geoff has a point, of REST being simple enough to be able to easily implement without the overhead of a framework, I think there is more to REST (once you start implementing it on a large scale within an organization). I see a lot of arguments on this board with people refering to something related to writing scope limited (small business) applications. In that case, RoR is your answer. Actualy, you can use simple CGI. I can implement a REST service in less than 20 lines of code.

    Now, when complexity and enterprise SOA architecture kicks in, then we start thanking Java (it's outstanding OO facilities) and it's frameworks.

    The other day I tried to implement a REST web service in Perl. Note, I used to be a very heavy perl programmer, have a published book, etc..., but after many years in OO, I actualy tried to implement a consumable REST service, using OO methodologies and design patterns. Hmmm, Perl is not very friendly in doing this. Not sure about Ruby, though I posted a question to a Ruby board the other day, asking for an equivalent of a Java interface, still no response. I just can't picture writing programs without interfaces any more, even if you have multiple inheritance ability. Abstract classes are not the same.

    So I'm back to Java and it's variety of great/extensible frameworks.

    Sorry, I think I went a bit OT.

    Ilya
  14. pretty silly[ Go to top ]

    Actually, I think Geoff has a point. So far as I can tell from the example, RESTful JAX-WS is more complicated then just banging out a servlet to do the same thing.
    Marc Hadley had a similar post a week ago. Mark Baker (a leading proponent of REST) seems to support your view.
    http://www.markbaker.ca/2002/09/Blog/2006/01/19#deliciousdistobj.Marc_Hadley_s_B...AX_WS