InfoQ

Presentation

Recorded at:
Recorded at

REST Eye for the SOA Guy

Posted by Steve Vinoski on Jul 15, 2008 04:20 PM

Community
SOA
Topics
REST,
Design
Tags
QCon San Francisco 2007,
QCon
Summary
In a presentation recorded at QCon San Francisco, CORBA guru Steve Vinoski introduces REST from the perspective of a traditional SOA person. He explains the goals of the various constraints REST imposes, and the desirable properties one can gain from adhering to them. In a hypothetical discussion with a "SOA guy", Steve addresses various frequent doubts people express when they first look at REST.

Bio
Steve Vinoski is a very well-known expert on middleware, mostly known for his long-time involvement with CORBA. He is a member of technical staff at Verivue and was previously chief architect and Fellow at IONA Technologies for a decade. Over the past 15 years, Steve has authored or co-authored over 80 highly-regarded publications on distributed computing and enterprise integration.

About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.

6 comments

Reply

REST by Mark Richman Posted Jul 17, 2008 4:20 PM
Re: REST by Steve Vinoski Posted Jul 18, 2008 3:02 PM
REST by Torsten Mielke Posted Jul 18, 2008 10:19 AM
Re: REST by Steve Vinoski Posted Jul 18, 2008 3:06 PM
Re: REST by sanane zorlayin Posted Aug 8, 2008 3:12 AM
Re: REST by sanane zorlayin Posted Aug 8, 2008 7:12 AM
  1. Back to top

    REST

    Jul 17, 2008 4:20 PM by Mark Richman

    Seems like the issue today is not so much SOAP vs. REST, but the backlash against interface/contract based programming in general.

    This raises the issue of versioning/deprecating interfaces (or resources).

    For me, I see issues with service discovery (a la WSDL) with REST, as there is no way that I can see for a consumer to learn a REST service's API without referring to human-readable documentation. With SOAP, we have the ABCs (address-binding-contract). With REST, the A and B are implicit, which leaves C.

    What I'd like to see happen for REST to mature is a simple way to describe the exchange of documents (messages), and not just serialize objects, which is all the SOAP/WSDL/XSD mess really describes. In the end, I guess REST is about semantics and SOAP is about syntax.

    There is certainly some room for REST to "grow up" with little used HTTP 1.1 verbs such as OPTIONS, HEAD, TRACE, and CONNECT and header fields.

    Thanks,

    Mark

  2. Back to top

    REST

    Jul 18, 2008 10:19 AM by Torsten Mielke

    This was a very valuable presentation which I watched with great interest. You said: "Specialized interfaces inhibit scalability" and inhibit reuse as they require custom code clients. I fully agree with that remark. However does the need for specialized data not inhibit reuse and scalability just as much as specialized interfaces? Don't we spend far more lines of application code on setting up our specialized data structures than on calling the actual specialized interface of a service? Does offering a uniform interface while still having specialized data structures really increase reusability and therefore scalability? I kind of question that but would like to get others opinions as well.

  3. Back to top

    Re: REST

    Jul 18, 2008 3:02 PM by Steve Vinoski

    Hi Mark, thanks for your comments.

    As I once remarked in a blog entry, I've never seen anyone develop an IDL/SOAP/WSDL-based client without referring to human-readable documentation. Nobody writes a client that simply goes out, discovers such services, and starts using them. Among other problems, the specialized interfaces required to communicate with the newly-discovered service makes this hard to do. Keep in mind that each specialized service interface is effectively a new application protocol.

    IMO you have a better chance at this with REST due to the very important HATEOAS constraint: "hypermedia as the engine of application state." The representations returned by resources direct the client through the application state by giving it hyperlinks and form metadata so it knows what to do next. The client must understand the media type of the resource representation, of course, but the fact that media types are globally standard types registered with the IANA means that clients and servers can be independently developed against them. This is quite different from the specialized data types for each specialized interface that IDL/WSDL encourage, which ends up discouraging independent development of client and server.

  4. Back to top

    Re: REST

    Jul 18, 2008 3:06 PM by Steve Vinoski

    Hi Torsten, I hope all is well and thanks for your feedback.

    This is a REST frequently-asked question, and if I recall correctly it was even asked by some of the attendees (Glen and Sanjiva IIRC) during the presentation. It's such a common question that I wrote a whole column about it earlier this year: please read "Demystifying RESTful Data Coupling" as I believe it will answer your question.

  5. Back to top

    Re: REST

    Aug 8, 2008 3:12 AM by sanane zorlayin

  6. Back to top

    Re: REST

    Aug 8, 2008 7:12 AM by sanane zorlayin

    Adidas Ayakkabı, Boot, or Nike , UGG Bot, Online Shoping, Nike Shophing, Turkey Nike Online Giyim Adidas Ayakkabı Nike Ayakkabı Adicolor UGG Bot

Exclusive Content

VMware Infrastructure 3 Book Excerpt and Author Interview

VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.

Architectures of extraordinarily large, self-sustaining systems

Can a system that is so large it cannot be comprehended be "designed" in a conventional sense? The foundations of computing are about to change. In this talk, Richard P. Gabriel explores why and how.

Using Ruby Fibers for Async I/O: NeverBlock and Revactor

Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.

Agile and Beyond - The Power of Aspirational Teams

Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.

Concurrency: Past and Present

Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.

ActionScript 3 for Java Programmers

Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.

Neal Ford On Programming Languages and Platforms

Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.

Future Directions for Agile

David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.