• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Developing Distributed Web Applications, Where does REST fit in?

Developing Distributed Web Applications, Where does REST fit in?






Total Views
Views on SlideShare
Embed Views



28 Embeds 426

http://srinathsview.blogspot.com 297
http://srinathsview.blogspot.in 50
http://srinathsview.blogspot.ca 11
http://srinathsview.blogspot.co.nz 10
http://srinathsview.blogspot.co.uk 10
http://srinathsview.blogspot.com.es 5
http://srinathsview.blogspot.com.au 5
http://srinathsview.blogspot.fr 5
http://srinathsview.blogspot.de 5
http://srinathsview.blogspot.hk 3
url_unknown 3
http://srinathsview.blogspot.mx 3
http://srinathsview.blogspot.nl 2
http://srinathsview.blogspot.it 2
http://srinathsview.blogspot.se 2
http://srinathsview.blogspot.ie 1
http://srinathsview.blogspot.kr 1
http://srinathsview.blogspot.cz 1 1
http://people.apache.org 1
http://srinathsview.blogspot.ru 1
http://srinathsview.blogspot.dk 1
http://srinathsview.blogspot.pt 1
http://translate.googleusercontent.com 1
http://srinathsview.blogspot.co.il 1
http://srinathsview.blogspot.tw 1
http://webcache.googleusercontent.com 1
http://srinathsview.blogspot.com.ar 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.


11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Developing Distributed Web Applications, Where does REST fit in? Developing Distributed Web Applications, Where does REST fit in? Presentation Transcript

    • Developing Distributed Web Applications, Where does REST fit in?
      Dr. Srinath Perera
      Senior Software Architect, WSO2 Inc.
      Visiting Faculty, University of Moratuwa
    • What is a Distributed Web Application?
      Users access a one server (or he thinks he does) while really the app is composed of many machines.
      Why “Distributed”?
      for scaling. Single machine can not handle the load
      High availability
      photo by arvindgrover on Flickr, http://www.fotopedia.com/items/flickr-3154212659
    • Google as a Distributed Web Application
      Google crawls the Web and stores all (well most of ) the Web
      It builds indexes for included words and incoming links for each document
      When a user sends a query, it applies the Page Rank Algorithm and returns the most relevant results.
      It is a distributed application that built using few 100k servers
    • Programming Distributed Web Applications
      Essentially (Web) applications deal with state (data) and operations (executions or processing units)
      Users talk to applications and either retrieve data or make changes to the current state.
      There are two primary architectural models
      SOA (Service Oriented Architectures) : based on processing units (verbs)
      ROA (Resource Oriented Architecture): based on data(nouns)
      photo by QolePejorian on Flickr, http://www.fotopedia.com/items/flickr-184160623
    • SOA (Service Oriented Architecture)
      There are many stateless processing units (often grouped as services)
      Users provide data to processing units, and they either return data after processing or change the system wide state (e.g. stored in the database).
      A SOA based architecture includes a main storage (e.g. database) and many stateless processing units, and an application combines and composes those processing units together.
      E.g. Google has its indexes etc., and one main operation “search” that accepts a search query as a input and returns matching documents.
      Also implementation has many internal services
      photo by L. Marie on Flickr, http://www.flickr.com/photos/lenore-m/312319615/
    • ROA (Resource Oriented Architecture)
      There is a resource structure
      Each resource supports four operations, PUT, GET, POST, DELETE
      Users retrieve information through GET and change system state through POST, DELETE, and PUT
      The architecture is based on resources (nouns) and processing is represented through four verbs on the resource.
      photo by Svadilfari on Flickr, http://www.flickr.com/photos/22280677@N07/2435832518/ (CC)
    • ROA vs. SOA
      There are lots of fights, which I am not going to discuss in detail.
      Argument is Web uses ROA, and it works.
      SOA is much closer to the programing models we used to with languages like C or Java. So that is natural to us.
      I would say, they are two useful styles, and we have to know both and use them where it naturally fits.
      I will focus more on ROA for this discussion.
      photo by hans s on Flickr, http://www.flickr.com/photos/archeon/2359334908/
    • REST (Representational State Transfer)
      ROA is realized with REST services or HTTP services (Good intro to REST, http://www.infoq.com/articles/rest-introduction)
      Main principles of REST
      Give everything an ID (URI)
      Things (resources) refer to each other
      All interactions are done through four verbs (PUT, GET, DELETE, POST) on resources
      Photo by paraflyer on Flickr, http://www.fotopedia.com/items/flickr-386529128
      Resources can return multiple formats (choosed based on content negotiation)
      All communication are stateless (each request has all the information need to serve the request)
    • Example: Web App to Manage a Network
      Assume we want to build a Web app to manage networks. Users can view, query, and change the network configurations through this Web App.
      Lets see how this would look with both SOA and REST
      Photo by sylviaduckworth on Flickr, http://www.geograph.org.uk/photo/956353
    • With SOA
      Architecture will include a database to hold network data and services supporting following operations
      SearchNetworks(String queryParams)
      Notice Each operation is a Verb, users combine those verbs to do what he needs
      Message formats are defined through a WSDL and each service supports one message format.
    • With REST
      Give everything a ID (URI)
      Things (resources) refer to each other
      Retrieving a network will return something like
      <cse ref=“http://uom.lk/Networks/CSE”/>
      All interactions are done through four verbs (PUT, GET, DELETE, POST) on resources
      GET on http://uom.lk/Networks/CSE : Getting network data
      POST on http://uom.lk/Networks/CSE: update the network config.
      DELETE on http://uom.lk/Networks/CSE can delete the network etc.
    • With REST (Contd.)
      Resources can return multiple formats
      Results can return multiple formats, XML, Jason, Binary or several XML formats etc.
      Clients send the header Accept: text/json, text/xml+foo defining supported formats, and the server returns result in a format client supports. This means a resource can support multiple formats at the same time. Also we can use this to support new formats later.
      All communication is stateless – this is same for SOA and ROA
      System can use HTTP style caching
    • Implementing REST Services
      Define the resources structure
      Define many URLs for different types of resources
      Use a REST engine to attach code to each URL patterns, they support four verbs (e.g. see http://www.sinatrarb.com/intro)
      Code segment is for URL, verb, content type
      On GET text/xml do
      Photo by Kevin Dooley on Flickr, http://www.flickr.com/photos/pagedooley/2201791390/
    • REST Anti-patterns
      Verbs in URLs
      This is doing SOA using HTTP, not REST
      Ignoring status codes on responses
      Not including references in responses
      <subnetmask> ..</subnetmask>
      Use references whenever that makes sense, do not copy data in to response. Remember the underline linked resource structure.
    • REST, is it the Architecture to solve them all?
      Does the REST a silver bullet for all problems
      This is the source for most fights, the answer looks “No”. Some examples.
      It does not have a contract (Lack a WSDL)
      Messaging – does not talk about eventing/ messaging aspects. May be need a SUBSCRIBE verb added.
      Asynchronous invocations and reliability
      What about composition and transactions etc. mostly things come from WS-*
      Does error messages are enough?
      Photo by Playaduraon Flickr, http://www.flickr.com/photos/playadura/1401756881
    • So when to use it?
      Use when REST is the natural choice
      It is very good at representing resources
      Not that good with processes/ executions
      Same for SOA
      Is it OK to mix it?
      I would say yes, but not too much
      WSO2 use REST for registry API, while SOA for many other places.
      Photo by QUEEN YUNA on Flickr, http://www.flickr.com/photos/queenyuna/5710802864/ (CC)
    • Conclusion
      What is a Distributed Application?
      SOA and ROA as solutions
      Detailed looked at ROA with a Example
      It is the architecture that solves everything? “Look like we need both”
    • For more information
      Stefan Tilkov: A Brief Introduction to REST, http://www.infoq.com/articles/rest-introduction
      Stefan Tilkov: REST Anti-Patterns, http://www.infoq.com/articles/rest-anti-patterns
      More articles here http://en.wikipedia.org/wiki/Representational_State_Transfer
      SanjivaWeerawarana: WS-* vs. REST: Mashing up the Truth from Facts, Myths and Lies, http://wso2.org/library/2818
    • Questions?