Discussions

News: RESTful Web Services article from SDN

  1. RESTful Web Services article from SDN (13 messages)

    "RESTful Web Services" is an article by Sameer Tyagi, published on SDN, that discusses the use of REST through the JAX-WS apis, as shown in the Java EE Blueprints Catalog. The article shows how REST works (including the four verbs normally associated with it) as well as the mechanisms for publishing and consuming RESTful services as the standard APIs propose. One very useful part of the article discusses when architects might want to use REST vs. SOAP:
    Architects and developers need to decide when this particular style is an appropriate choice for their applications. A RESTFul design may be appropriate when:
    • The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server.
    • A caching infrastructure can be leveraged for performance. If the data that the web service returns is not dynamically generated and can be cached, then the caching infrastructure that web servers and other intermediaries inherently provide can be leveraged to improve performance. However, the developer must take care because such caches are limited to the HTTP GET method for most servers.
    • The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data being exchanged and on ways to process it meaningfully. In the real world, most commercial applications that expose services as RESTful implementations also distribute so-called value-added toolkits that describe the interfaces to developers in popular programming languages.
    • Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited-profile devices such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted.
    • Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style. Developers can use technologies such as Asynchronous JavaScript with XML (AJAX) and toolkits such as Direct Web Remoting (DWR) to consume the services in their web applications. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly refactoring the existing web site architecture. Existing developers will be more productive because they are adding to something they are already familiar with, rather than having to start from scratch with new technology.
    A SOAP-based design may be appropriate when:
    • A formal contract must be established to describe the interface that the web service offers. The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.
    • The architecture must address complex nonfunctional requirements. Many web services specifications address such requirements and establish a common vocabulary for them. Examples include Transactions, Security, Addressing, Trust, Coordination, and so on. Most real-world applications go beyond simple CRUD operations and require contextual information and conversational state to be maintained. With the RESTful approach, developers must build this plumbing into the application layer themselves.
    • The architecture needs to handle asynchronous processing and invocation. In such cases, the infrastructure provided by standards such as WSRM and APIs such as JAX-WS with their client-side asynchronous invocation support can be leveraged out of the box.
    The conclusion of the article sums up what the author is trying to communicate:
    JAX-WS provides comprehensive support for building web services. Developers can leverage the capabilities of this API to build and consume a variety of web services, whether those services are based on WSDL or are RESTful in behavior. The combination of the Provider and Dispatch interfaces allows web services to be built and consumed, and it provides developers with the flexibility to process the messages sent over the wire in a variety of ways. In addition, the future holds the possibility of describing RESTful web services for tools to consume, which will further simplify the developer's experience.
    However, the amount of code involved in using the APIs - even with annotation and API support - is staggering. What's your approach, and what's your opinion of it?

    Threaded Messages (13)

  2. JAX-WS vs Servlet API[ Go to top ]

    The main contribution of this article is to show that the new JAX-WS API let you build RESTful web services, if you want to. However, at first glance, it is not obvious (to me) in which way using JAX-WS would be better than using the classic Servlet API in order to implement RESTful services in java. Comments, anyone?
  3. Re: JAX-WS vs Servlet API[ Go to top ]

    The main contribution of this article is to show that the new JAX-WS API let you build RESTful web services, if you want to. However, at first glance, it is not obvious (to me) in which way using JAX-WS would be better than using the classic Servlet API in order to implement RESTful services in java. Comments, anyone?
    May build a new and only RESTful service it is not better than a Servlet API implementation. However, build a RESTFul face for a existent Web Service its is another thing ...
  4. "staggering"?[ Go to top ]

    Sorry, Joseph, can't let that stand. To my eye there's nothing exceptionally bulky or cryptic about the examples. Did you have something specific in mind?
  5. Bandwidth is particularly important and needs to be limited.
    Wow! could not believe my eyes when I read it! Does sanity have now a chance to prevail? For all concerned about efficiency and convenience I suggest looking at Hessian (especially for limited capability devices). And of course have a careful look at CORBA and ICE
  6. I'm quite sick of people mapping HTTP verbs to SQL statements, as opposed to object operations. The correct mapping, IMO, is new=PUT, access=GET, modify=POST, method-invocation=OPTION and delete=DELETE. I love REST because it can address objects (with resource URIs) and express operations on objects with HTTP verbs (operations on resources). What SOAP web services (i.e., RPC with buzzwords) are still lacking is objects.
  7. I'm quite sick of people mapping HTTP verbs to SQL statements, as opposed to object operations.

    The correct mapping, IMO, is new=PUT, access=GET, modify=POST, method-invocation=OPTION and delete=DELETE.

    I love REST because it can address objects (with resource URIs) and express operations on objects with HTTP verbs (operations on resources).

    What SOAP web services (i.e., RPC with buzzwords) are still lacking is objects.
    Hi, I like the simplicity of REST, and I like the idea of a uniform connector, but when it comes to verbs the set available in HTTP are just two limiting to be generally applicable IMO. I would love to be proven wrong. Please explain further. In particular, please explain what you mean by:
    method-invocation=OPTION As I understand it, such an approach is not strictly RESTful. For example: GET www.server/myresource&method-invocation=delete breaks the REST constraint of no new verbs. Also it is ambiguos because here we have two verbs (get and delete) in one command. Paul.
  8. I'm quite sick of people mapping HTTP verbs to SQL statements, as opposed to object operations.

    The correct mapping, IMO, is new=PUT, access=GET, modify=POST, method-invocation=OPTION and delete=DELETE.

    I love REST because it can address objects (with resource URIs) and express operations on objects with HTTP verbs (operations on resources).

    What SOAP web services (i.e., RPC with buzzwords) are still lacking is objects.
    Hi, I like the simplicity of REST, and I like the idea of a uniform connector, but when it comes to verbs the set available in HTTP are just two limiting to be generally applicable IMO. I would love to be proven wrong. Please explain further. In particular, please explain what you mean by:
    method-invocation=OPTION
    As I understand it, such an approach is not strictly RESTful. For example: GET http://www.myserver.com/myresource&method-invocation=delete breaks the REST constraint of no new verbs. Also it is ambiguos because here we have two verbs (get and delete) in one command. Paul.
  9. I'm quite sick of people mapping HTTP verbs to SQL statements, as opposed to object operations.

    The correct mapping, IMO, is new=PUT, access=GET, modify=POST, method-invocation=OPTION and delete=DELETE.

    I love REST because it can address objects (with resource URIs) and express operations on objects with HTTP verbs (operations on resources).

    What SOAP web services (i.e., RPC with buzzwords) are still lacking is objects.


    Hi,

    I like the simplicity of REST, and I like the idea of a uniform connector, but when it comes to verbs the set available in HTTP are just two limiting to be generally applicable IMO. I would love to be proven wrong. Please explain further. In particular, please explain what you mean by:

    method-invocation=OPTION


    As I understand it, such an approach is not strictly RESTful.

    For example:

    GET http://www.myserver.com/myresource&method-invocation=delete

    breaks the REST constraint of no new verbs. Also it is ambiguos because here we have two verbs (get and delete) in one command.

    Paul.
    Hi Again, I shouldn't reply to my own posts, but I just had an idea. If the HTTP protocol was extended to include a new verb for remote method invocation then I think it would help. So for example: INVOKE http://myserver.com/myobject/methodName&param=2 Would at least solve the ambiguity problem. Not sure that it would satify the other constraints in Roy Fieldings REST disertation though. For example the constraint that allows for server caching. I just can't help feeling that HTTP is the wrong protocol for remote method invocation, but then again I can't stand SOAP. Paul.
  10. I guess no one wants to talk abiout REST. Well I've finally answered my own question:
    method-invocation=OPTION
    As I understand it, such an approach is not strictly RESTful. For example: GET http://www.myserver.com/myresource&method-invocation=delete breaks the REST constraint of no new verbs. Also it is ambiguos because here we have two verbs (get and delete) in one command.
    I was right. This is not strictly RESTful. My epiphany is that with REST direct method invocation just isn't needed. State transfer is perfectly adequate. A way of thinking about it is to see a GET/POST as a message transfer (message send=XML document transfer). The service (reciever object) is identified by the URL. As long as the client and server agree on the REPRESENTATION of the message body then everything will work fine. (The message implies the method(s) used by the server in processing). That's it. No more posts to myself. Paul.
  11. OPTIONS[ Go to top ]

    Sorry Paul, I was away on a trade show... First, it should have been OPTIONS and not OPTION, my typo. OPTIONS *is* one of the 8 HTTP verbs as are the familiar GET, POST, PUT and DELETE, and, TRACE, HEAD and CONNECT. OPTIONS allows a request body as in PUT and POST. So you can have: OPTIONS /myclass/oid and feed the method's name (and the values of the possible arguments to it) to the stream and the server side can identify the object and invoke the method with the given parameters. This is not truly RESTful, as many will observe, as the HTTP RFC clearly states that the use of the OPTIONS verb should not have side-effects on the resource: an object's methods can modify the object. Still, it can be used for invoking methods. "Delete" is not a method but an operator in OOP. Maybe you were thinking of destructors?
  12. web services based oon REST[ Go to top ]

    Hi, Can u please send me an detail example . how to create a web service using REST. I am using Java technology. please consider it. Thanks in advance.
  13. web services based oon REST[ Go to top ]

    Hi, Can u please send me an detail example . how to create a web service using REST. I am using Java technology. please consider it. my mail id is eeswari dot kureti at gmail dot com Thanks in advance.
  14. More comments[ Go to top ]

    I agree with the comments some of the folks made on this article. I just posted some more comments at http://www.subbu.org/weblogs/main/2006/08/jaxws_for_restf_1.html. IMO, this article is a stretch on several counts. JAX-WS is not the best solution for REST based services.