InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Presentation: REST: A Pragmatic Introduction to the Web's Architecture

Posted by Abel Avram on Jan 30, 2009

Sections
Architecture & Design,
Enterprise Architecture
Topics
WOA ,
SOA ,
Architecture ,
REST
Tags
WADL ,
Design Guideline ,
Web services ,
Caching ,
QCon London 2008 ,
QCon ,
Web Browser ,
Web Server

In this presentation recorded during QCon London 2008, Stefan Tilkov introduces the audience to REST seen as an architectural style. He thinks that REST is not an alternative to SOA but it can serve SOA to reach its goals. Stefan also covers other related topics: HTTP, WS-*, SOAP, CORBA, RPC, enterprise, in an attempt to make the listeners understand what REST is and what is not and how it helps.

Watch: REST: A Pragmatic Introduction to the Web's Architecture (1h)

Stefan offers three SOA definitions:

  • An approach to business/IT alignment
  • A technical architecture
  • The architecture binding web services

Stefan continues with three definitions of REST:

  • An architectural style - the correct and complete definition as given by Roy Fielding
  • The web used correctly – using HTTP in a REST-ful way
  • XML without SOAP – XML transferring without the SOAP envelope. This should be avoided as REST definition.

Following, Stefan takes the second definition, REST-ful HTTP, and explains it:

  • Every resource should have an ID
  • Link resources through their IDs
  • Make use of standard methods to transfer resources: GET, PUT, POST, DELETE
  • A resource identified by its ID should be allowed to have multiple representations
  • Stateless communication

Stefan continues by explaining how to design a good RESTful application and gives a simple example using pseudo-code. He also presents some of the features and advantages HTTP has, and talks about HTTP, REST, SOA, WS-*, Internet, enterprise for the rest of the session which is concluded by Stefan taking questions from the audience.

  • This article is part of a featured topic series on SOA
Well-balanced introduction to REST by Raj Bhandari Posted
Re: Well-balanced introduction to REST by Jean-Jacques Dubray Posted
Re: Well-balanced introduction to REST by Stefan Tilkov Posted
Re: Well-balanced introduction to REST by Jean-Jacques Dubray Posted
Re: Well-balanced introduction to REST by Stefan Tilkov Posted
Data size and complexity by Rafiq Ahmed Posted
  1. Back to top

    Well-balanced introduction to REST

    by Raj Bhandari

    This is probably the first comparison of REST Vs SOA, WS.*, SOAP that explains how they can be compared.

  2. Back to top

    Re: Well-balanced introduction to REST

    by Jean-Jacques Dubray

    It would be interesting to get Stefan's opinion of Ross Altman's latest presentation. Ross is one of Sun's CTOs (for Business Integration) and he explains:

    Assumption: RESTful Web services should be used instead of WS-* Web services

    A case can be made for the use of RESTful services for Opportunistic applications. However, for Systematic applications, the Qualities of Service that are required would have to be built on an ad hoc basis.

    As a result, the cost of RESTful services would go up and interoperability would go down
    If the counterparties building a RESTful interaction have to “reinvent the wheel” of runtime governance standards, the costs and complexity of RESTful Web services would increase dramatically, undermining the attractiveness of the REST model

    Since the runtime management capabilities for each RESTful Systematic application would be developed in a non-standard way, interoperability between RESTful implementations would drop drastically

    When do you think we can throw darts at REST-*?

  3. Back to top

    Re: Well-balanced introduction to REST

    by Stefan Tilkov

    As you're asking for my opinion: No, I don't believe that WS-* will have to be re-invented for RESTful HTTP. For example, I believe that there are many, many more opportunities for runtime governance of RESTful HTTP services already, as the infrastructure has much more visibility into the messages flowing through it.

  4. Back to top

    Re: Well-balanced introduction to REST

    by Jean-Jacques Dubray

    Hum... so if we take the elements of Runtime Governance for instance:

    - registry / repository
    - policies
    - security
    - change management
    - event management (as in Incident / Problem resolution)

    Could you explain how these pieces work in REST since there are no contracts, no boundaries, no policies, no agreed upon versioning capability, URIs are bolted on resource access operations (making it hard to deal with Change) and finally, how do you go about conducting a root cause analysis across a domain that has no autonomous boundaries (i.e. where the only explicit boundary is the network authority that owns a particular URI).

    When you build a Web App, you can monitor if it's up or down, and how it is behaving. When you cover a network authority with a series of "resources" where do you start when an event/incident/problem occurs? You go straight back to the design doc? you have no impact analysis capabilities?

  5. Back to top

    Re: Well-balanced introduction to REST

    by Stefan Tilkov

    Sorry for noting your comment so late.

    1) Are you suggesting there are widespread runtime governance standards for WS-*? Like what? UDDI? Currently, every governance product uses its own proprietary approach.

    2) You are free to use XML Schema, as much as you want to, when using RESTful. If you want to base part of your governance on the evolution of schemas, nothing stops you.

    3) There is no versioning support in WS-* that I'm aware of. The stuff I've read about it (including yours) talks about options for XML Schema versioning, which IMO a) still sucks b) is available for REST/HTTP if you disagree

    4) While I've seen tons of articles and presentations discussing the use of policies for governance, I've never seen it applied in practice.

    5) The impact analysis support I've seen in governance product requires additional metadata that has to be explicitly added, such as usage relationships between consumers and providers. This seems to be entirely orthogonal to the REST vs. WS-* discussion in my view.

    6) I fail to see how URIs make it hard to deal with change - in fact I disagree strongly. They offer a workable means to support old, new and unknown clients that I've not seen in the WS-* world.

    7) How are incident management and REST/WS-* related?

  6. Back to top

    Data size and complexity

    by Rafiq Ahmed

    As methods like POST, GET has data size constrain, number of byte you can send. How can we send large data?

    Or better I want to know,if we building system with lot and lot of complex data. Is REST is good choice ? Possibly we can do it in REST.Amount of effort we put for development and maintaining the application will be huge as compare to using WS based on SOAP.

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.