Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News Presentation: Steve Vinoski on REST

Presentation: Steve Vinoski on REST

In a new presentation, recorded at QCon San Francisco, CORBA guru Steve Vinoski introduces REST with a focus on those with a more "traditional" SOA background.

Steve 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. He explains many of the constraints of REST and the reason behind them.

The video only captures the very lively discussion during the session, but Steve put in an effort to repeat most, of not all, of the questions by the audience, which included industry luminaries such as Sanjiva Weerawarana, Glen Daniels (both from WSO2) and REST expert Stu Charlton (then BEA).

Steve Vinoski, who has also written an article for InfoQ about using Erlang to develop RESTful services and was interviewed on his views on REST, middleware, and programming languages before, 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. Since he has left IONA, he has become a very vocal proponent of the REST style.

Check out Steve's presentation
(57 minutes).

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • REST

    by Mark Richman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

    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.



  • REST

    by Torsten Mielke,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: REST

    by Steve Vinoski,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: REST

    by Steve Vinoski,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.