Sign In/My Account | View Cart  
advertisement


Listen Print Discuss

REST and the Real World
by Paul Prescod | Pages: 1, 2, 3, 4

REST limitations

There is no free lunch. REST is not a panacea. The biggest problem most will have with REST is that it requires you to rethink your problem in terms of manipulations of addressable resources instead of method calls to a component. Of course you may actually implement it on the server side however you want. But the API you communicate to your clients should be in terms of HTTP manipulations on XML documents addressed by URIs, not in terms of method calls with parameters.

Your customers may well prefer a component-based interface to a REST interface. Programmers are more used to APIs and APIs are better integrated into existing programming languages. For client-side programmers, REST is somewhat of a departure although for server-side programmers it is not much different than what they have been doing for the last several years, building web sites.

REST is about imposing a programming discipline of many URIs and few methods. RPC allows you to structure your application however it feels best to you. Let it all hang out! If a particular problem can be solved with RPC, and future extensibility and security are not going to be issues for you, you should certainly use the looser approach.

HTTP is also not appropriate in some circumstances. Because HTTP runs on top of TCP, it can have high connection times compared to protocols intended first and foremost for efficiency. HTTP is designed primarily for the kind of coarse-grained interactions that are used on the public internet, not the kind of fine-grained ones that might be appropriate on a single desktop, within a department or even in certain enterprise situations.

Once again, if DCOM or CORBA solves your fine-grained problem then there is no reason to move to REST. In my opinion, REST will first dominate primarily in the world of partner-facing, external Web Services. Once this happens, it will start to migrate to the Intranet, just as the Web did.

The Best Part

The best part about REST is that it frees you from waiting for standards like SOAP and WSDL to mature. You do not need them. You can do REST today, using W3C and IETF standards that range in age from 10 years (URIs) to 3 years (HTTP 1.1).

Whether you start working on partner-facing web services now or in two years, the difficult part will be aligning your business documents and business processes with your partners'. The technology you use to move bits from place to place is not important. The business-specific document and process modeling is.

There is no doubt that we need more standards to make partner-facing web services into a commodity instead of an engineering project. But what we need are electronic business standards, not more RPC plumbing. Expect the relevant standards not to come out of mammoth software vendors, but out of industrial consortia staffed by people who understand your industry and your business problems -- and not networking protocol wonks like Don Box and myself.

REST does not offer a magic bullet for business process integration either. What REST brings to the table is merely freedom from the tyranny of proprietary addressing models buried in RPC parameters. Do not be afraid to use hyperlinks and URI addresses in your business documents and processes. Specifications like SOAP and WSDL may make that near impossible, but that is a problem with those specifications, not with your understanding of your problem. If you use hyperlinks in your business document and process modeling (as you should) then there is a protocol that does not get in your way: HTTP.

REST: Everything Old is New Again

The rhetoric around web services describes them as "like the web, but for machine to machine communications." They are said to be a mechanism for publishing processes as the Web published data. REST turns the rhetoric into reality. With REST you really do think of web services as a means of publishing information, components and processes. And you really do use the technologies and architecture that make the Web so effective, in particular URIs, HTTP and now XML.

Thanks to Jeff Bone and Mark Baker for some core ideas.

Comment on this articleDoes REST make sense for you? Share your views in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

Titles Only Titles Only Newest First
  • REST
    2004-07-10 06:18:14 johnfitzpatrick [Reply]

    This article gave me a whole new way of thinking and I really appreciate that. The simplicity of this approach is truly compelling and as pointed out in the beginning of the article, it's the simplicity of concepts like HTTP and XML that make them useful and extensible.


    Thanks,
    John Fitz

  • REST and the REAL browser
    2003-03-31 10:29:07 Rein Petersen [Reply]

    I've been building my platform with principles that are very similar to REST long before I had even heard of REST. One issue that is clear to me is the power available to clients. That is, the traditional browser **ONLY** supports GET and POST with exception of some ActiveX (ie MS's msxml) and I suppose other Java applets. I would love to enjoy the use of other verbs (PUT,DELETE,HEAD) but unless I'm designing fat clients or server-server processes, it's likely I'll have to fudge the ideal and cram PUT,DELETE,HEAD inside POST... what a drag...
    Rein

  • SOAP and XML
    2002-11-25 12:58:52 Gary Hewitt [Reply]

    So let's assume the following:
    Given any problem, XML is the solution.
    SOAP seems to solve the problem in the wrong way: by using XML as a transport mechanism/envelope for other datatypes. So you can marshall datatypes, but also do things like guarantee delivery (maybe), apply security (again, maybe), etc.


    Seems like the elephant in the middle of the party is that XML seems far more powerful as a datatype itself ... but transmitting XML documents is ugly in SOAP.


    It seems graceful in REST, however, where the URI can (should?) point at an XML document.


    If I were trying to create interfaces to existing components (COM, J2EE classes) I think SOAP would be very attractive to shorten that process; I'm in green fields, though, and REST looks much more attractive as an approach, esp. since many of my resources are not particularly state-dependent.

  • You've really got something, here's a question
    2002-04-18 17:59:18 Ben Bryant [Reply]

    You mention that "Google offers to its paid subscribers the ability to have search results published as XML". Today Simon St.Laurent pointed out on xmlhack.com that Google is embracing SOAP (I am downloading Google's toolkit to check it out), perhaps for non-paying users?


    I couldn't agree with you more that the "WebService.stockQuote("KREM")" proprietary syntax will always eventually be "rendered irrelevant" by the likes of "http://www..../webservice/stockquotes?KREM", and I applaud how well you expressed this.


    One of themes I see in this recurring detour pattern in the Web Services industry is that few programmers come to grips with the fundamentals of distributed asynchronous application development. So they get it done using a more RPC-style solution, or the latest much-hyped proprietary thing that seems at first to do all the work for you. But hey if they get "something" working adequately ya gotta give em credit.


    Any business collaboration requires a great deal of coordination, there's no getting around it. Say Google publishes this service now, in the next go around they will improve upon aspects of it due to customer feedback.


    Whether they used a REST solution or SOAP, they will probably provide new improved services at a slightly different location (a new URI in the case of REST, a new object in the case of SOAP), and phase out old versions of the service at later points in time.


    But I think that on the face of it a responsible business software developer should stick with the proven and lasting fundamentals, given the opportunity. And the nice thing is that this is not something new to wait for.


    We already have a de-facto universal identifier, and its a URI, and that when this wave of global identifiers and remote call syntaxes goes out of fashion like the wave before it, URIs, GET and POST will still be here.


    I had more to say but when I looked back into your articles I realized you've already said it better. Great work. You are right on the mark.




  • Re: Is REST really a subset of Web
    2002-03-19 14:05:50 Sean McRae [Reply]

    >> Okay, but if you're using HTTP and WSDL, then you aren't using SOAP


    Good point, but I still get the benefits of a URI-centric access method and can also support SOAP/RPC clients with the same code base and even the same code instance. Such a service is approachable to both communities.



    >> WSDL is a fairly poor interface definition language for web services built using a web architecture.


    I haven’t yet run into the limiting factors to which you refer, but I’m sure there are some there. WSDL is still in its first release. Like all standards it will evolve. WSDL does have the significant benefit of vendor support from most if not all the vendors who matter. The tools are emerging, corporate investment in WSDL will follow soon. I think the train is leaving the station.



    >> As soon as you follow a hyperlink to another web resource,…


    This seems to imply that a human using a browser as the end user or a web service. I’m not sure that’s the case in this first generation of web services. This may be too limiting a view (I’m still working on it) but I see the direct end user of a web service in its current state as someone who’s writing software (e.g. Java, C#, a scripting language, an Excel macro, etc.). As the presentation standards have not yet been set in the WS community, I’m not sure we can say web services of any stripe are much more than an API at this point in time. Or in other words, there’s a fundamental difference between using a web service and using a web service client.



    >> There are a couple of projects working on that [a service description standard for REST]


    I’m not sure REST is even in the web services game until there is such a standard. To me, the service definition is what gives web services its potential to be what the MBA’s like to call a disruptive technology. My company, like many others, has been putting services on the web since the mid/late 90’s. To a degree, they are all URI based. A standard absent a service description language does not bring much that’s new to the table. The language doesn’t have to be WSDL. There are many who would prefer RDF or some other standard that addresses something WSDL does not. It is the service contract, expressed in an industry-standard way, which is the essence of a web service, IMO.



    >> The REST static description languages under development are much simpler, easier to work with and yet more powerful than WSDL


    Perhaps, but the complexity issue may turn out to be a distinction without a difference. My only real web services work thus far has been with Visual Studio.NET. I’ve written a web services wrapper for one of our existing API products – and I didn’t write a line of XML, i.e. no WSDL and no SOAP. I simply added preprocessor instructions to native code and the framework generated the proxy classes and WSDL for me. Developing the client from VS.NET is done with similar ease; just import the WSDL file and the service and its methods are exposed as native objects. The complexity of WSDL and SOAP is completely encapsulated (alas, their limitations are not). While I don’t think Sun’s tools or any of the open source alternatives yet provide quite this level of abstraction, there’s no reason why they can’t, and I think they soon will. They just need to write transformations for native data types and method invocation to the SOAP equivalents and they can provide the same code generation features Msoft currently offers. Any organization serious about developing or using web services will be using tools like these, I think.


    Thanks for the reply.



    Regards,


    Sean McRae




    • Re: Is REST really a subset of Web
      2002-03-21 10:58:37 Paul Prescod [Reply]

      >> Okay, but if you're using HTTP and
      >> WSDL, then you aren't using SOAP


      > "Good point, but I still get the benefits of a URI-centric access method and can also support SOAP/RPC clients with the same code base and even the same code instance. Such a service is approachable to both communities."


      Unfortunately WSDL does not support REST as we'll discuss next so the point is sort of moot.


      >> WSDL is a fairly poor interface definition language for web services built using a web architecture.


      > "I haven’t yet run into the limiting factors to which you refer, but I’m sure there are some there. WSDL is still in its first release. Like all standards it will evolve."


      That's fine. But until it evolves support for REST it is my assertion that Internet-based e-business will not succeed. This will be blamed on a variety of factors but most will not realize that the failure was baked into the standards themselves.


      > "WSDL does have the significant benefit of vendor support from most if not all the vendors who matter. The tools are emerging, corporate investment in WSDL will follow soon. I think the train is leaving the station."


      The train can go as far as it wishes. When it becomes apparent that there is no engine we'll send another one after it. ;)


      >> As soon as you follow a hyperlink to another web resource,…


      > "This seems to imply that a human using a browser as the end user or a web service."


      No, and this is key to understanding why REST will work on the Web and SOAP/WSDL will not. In any programming language or API designed to solve real problems ("automateMyBusiness"), not toy problems ("getStockQuote") you need a way connect information bits together. In programming languages we have pointers or references. In databases we have foreign keys. In file systems we have absolute paths.


      Now consider this in a business messaging context. Any real business transaction must span many messages sent back and forth. These messages must refer and relate to each other somehow. SOAP and WSDL require you to build this relation yourself in a proprietary way. REST uses the standardized Web-way, which is the URI-bearing hyperlink. This has nothing to do with user interfaces and everything to do with building relationships between information components.


      > I’m not sure REST is even in the web services game until there is such a standard. To me, the service definition is what gives web services its potential to be what the MBA’s like to call a disruptive technology. My company, like many others, has been putting services on the web since the mid/late 90’s.


      Your two statements seem very odd beside each other? You've been solving the problem that people are trying to sell you tools to solve since the mid/late 90s, but you deny that the tool you are already using is "in the game."


      WSDL is not a disruptive technology. It is IDL for the Web, a rehash of a rehash of a rehash. Common wisdom is that the previous standards failed because there was no standardization between Microsot's COM and OMG's CORBA. That's a myth. Previous incarnations failed because the model *does not scale* across organizational boundaries. It requires too much coordination.


      And shared use of complex WSDL services requires more, not less, coordination than COM/CORBA because at least COM/CORBA had first-class pointer types. WSDL throws away all of the "loose coupling" advantages of XML. Two years ago it was common wisdom that the reason XML-based services would succeed where COM/CORBA ones failed was "loose coupling". Then WSDL came along and loose coupling was forgotten.


      > "To a degree, they are all URI based. A standard absent a service description language does not bring much that’s new to the table. The language doesn’t have to be WSDL. There are many who would prefer RDF or some other standard that addresses something WSDL does not. It is the service contract, expressed in an industry-standard way, which is the essence of a web service, IMO."


      WSDL service descriptions capture a tiny fraction of what you need to know in order to safely invoke a web service.


      >> The REST static description languages under development are much simpler, easier to work with and yet more powerful than WSDL


      > "Perhaps, but the complexity issue may turn out to be a distinction without a difference. My only real web services work thus far has been with Visual Studio.NET. I’ve written a web services wrapper for one of our existing API products – and I didn’t write a line of XML, i.e. no WSDL and no SOAP. I simply added preprocessor instructions to native code and the framework generated the proxy classes and WSDL for me. Developing the client from VS.NET is done with similar ease; just import the WSDL file and the service and its methods are exposed as native objects. The complexity of WSDL and SOAP is completely encapsulated (alas, their limitations are not)."


      The tool helped you to define a service that is exactly as tightly coupled as the COM+ service you could have defined two years ago or the CORBA service four years ago. Only the WSDL version is much less sophisticated. "Yesterday's technologies tomorrow."


      The service will be essentially impossible to evolve, it will be difficult to integrate with other, similar services and by definition it probably doesn't take advantage of XML standards in your industry. When someone elsewhere within Thomson publishes information that you would like to incorporate into your service you will have to do it through programming a bridge layer rather than simply making a hyperlink.


      REST is about moving to the next level, the level we were promised three years ago before the SOAP/WSDL detour.


      Paul Prescod


  • Re: Is REST really a subset of Web
    2002-03-19 09:08:00 Paul Prescod [Reply]

    "Consider that WSDL allows one to specify bindings for HTTP GET. Any XML/SOAP web service with this binding can be called via a URI with all the benefits of REST Paul outlines."


    Okay, but if you're using HTTP and WSDL, then you aren't using SOAP. So it isn't a subset, it's an alternative. Unfortunately, WSDL is a fairly poor interface definition language for web services built using a web architecture. The problem is that a WSDL defines *exactly one Web resource*. It's like having a very precise definition for one page of XML.com and the rest is undefined. As soon as you follow a hyperlink to another web resource, you have lost any of the static type checking features provided by WSDL. If you try to build a real application this way you will find that WSDL is next to useless.


    By the way, insofar as SOAP is designed to allow you to send messages to a SINGLE web resource end-point, you could actually think of it as limited compared to REST.


    "What REST seem to be missing is a means for self-description."


    There are a couple of projects working on that. My personal project is called WRDL and you can find it on www.prescod.net. Mark Baker is working on something based on RDF.


    "How do I as a client know what URI's are supported?"


    I would rephrase this as:


    * what XML document types and other media types are supported as inputs and outputs


    * what operations are available on them.


    People tend to over-emphasize URIs. URIs are the most critical technology, yes, but you don't go around building services by handing people lists of URIs. Rather you hand them a SINGLE URI and that resource will typically be represented by an XML document that can refer to other resources and so forth.


    "On the REST-ful client end I'm back to thumbing through (hopefully) up-to-date API documentation to get the syntax of each call."


    REST is just as amenable to static description as RPC is. The REST static description languages under development are much simpler, easier to work with and yet more powerful than WSDL. I suspect that the most important descriptive components of REST web services will be XML schemas (in whatever schema language).


    Paul Prescod


  • Is REST really a subset of Web Services?
    2002-03-18 12:10:08 Sean McRae [Reply]

    Is REST really a subset of XML/SOAP-style Web Services? I think it may be. Consider that WSDL allows one to specify bindings for HTTP GET. Any XML/SOAP web service with this binding can be called via a URI with all the benefits of REST Paul outlines. If you'd like to limit your client access to this type (and why would you?) just remove the other bindings from the WSDL.


    What REST seem to be missing is a means for self-description. How do I as a client know what URI's are supported? When a new URI has been added to the domain? How do I know what that the range or syntax of a value is for any given parameter is? What date format(s) does the service accept where there's a date value parameter? State code abbreviations or the full name of the state? Is seems a REST-ful web service will need a considerable amount of code that parses and validates parameter values; such work is not needed with the strong type checking available in SOAP-RPC. On the REST-ful client end I'm back to thumbing though (hopefully) up-to-date API documentation to get the syntax of each call. I can have that today without REST ;-)


    Regards.


    - Sean