• Like
REST: So What's It All About? (SAP TechEd 2011, MOB107)
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

REST: So What's It All About? (SAP TechEd 2011, MOB107)


Google and Twitter have been using it for years and now SAP has joined in with Project Gateway. So what is REST all about, how is it different from SOA-style integration and what could you use it for? …

Google and Twitter have been using it for years and now SAP has joined in with Project Gateway. So what is REST all about, how is it different from SOA-style integration and what could you use it for? This presentation will give you an overview of the concepts which define the REST architectural style and what has made it so popular with Internet companies and long-haired developers. You will also get some pointers on how to implement RESTful services in your SAP systems and expose your SAP systems to Web and mobile applications - both with and without Project Gateway! And to see all this in action, SAP Mentor John Moy will demo how a mobile Web application using jQuery Mobile can consume a RESTful service built in ABAP!

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • @soldner I'm glad it's helped. There is also a video of a slightly newer version of this presentation at http://vimeo.com/39673297‎
    Are you sure you want to
    Your message goes here
  • Thanks! I now think I get it!
    Are you sure you want to
    Your message goes here
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • This implies the client is the active party in the driving seat!The client doesn’t have to know or care about the server’s implementation – it only sees representations of internal (to the server) resources.
  • Example: a web page is just a representation of data held in the server’s database. Most sites don’t store the HTML in a file system but serialise their internal data and objects from a database into HTML using code!
  • By contrast SOAP uses HTTP is the dumb transport protocol. In fact, SOAP was designed to be transport-protocol agnostic – it is possible to use SOAP over SMTP or JMS! This means SOAP can’t assume that the transport protocol will do things reliably, so it doesn’t try. This leads to the need of yet another layer: WS-RM, and further complexity added to the whole stack!
  • This means there is not standard way for a client to know what service requests are idempotent, safe or cacheable!
  • Notice how the client is responsible for driving the process through to completion? The server simply responds to each request with some information and provides guidance on the next steps in the process which are available to the client. The client can choose to follow one of these, but doesn’t have to. This is practically identical to stateless web pages (e.g. stateless BSPs), and the opposite for transactional (stateful) applications such as Web Dynpro where the server maintains a session for each user and knows exactly what state each user is in.
  • Resource state != Application stateRequests from the client effect the transition of a resource from one state to anotherThe server uses a resource’s current state to determine what state transitions are available, and lets the client choose which one to effect.This is done through hyperlinks
  • The generation tools also allow creation of Gateway services from RFCs, BOR objects and even GUI screens.
  • Highlight that the Odata channel is really the preferred way of building Gateway services as it allows more complex use cases to be satisfied.
  • This is the Generation tool in Gateway 1.0 which will get you going very quickly from existing BAPIs or RFCs.
  • These payloads were generated by a Gateway 1.0 system. 2.0 may have introduced changes to the structure of these XML documents.
  • These payloads were generated by a Gateway 1.0 system. 2.0 may have introduced changes to the structure of these XML documents.
  • This is basically the same structure that Facebook implemented in their Graph API; there are more complex structures with more functionality but this was sufficient for our requirements.


  • 1. REST – So What’s It All About?
    MOB107 @ SAP TechEd 2011
    Las Vegas
  • 2. Agenda
    Applications in SAP-land
  • 3. Agenda
    Applications in SAP-land
  • 4. REST
  • 5. REpresentationalStateTransfer
  • 6. What Does That Mean?
  • 7. The Client communicates with the Server by modifying the state of Resourcesthrough Representations
  • 8. Representations?
    The server can store its data in whatever way it likes
    The client is unaware of this, and can store the same things differently
    Each party serialises its internal state into Representations
    This provides loose coupling!
  • 9. Everything has a URL
  • 10. URLs Identify Resources
    REST interfaces manipulate the state of resources
    “Process as a state machine/data flow diagram”
    Resource-oriented decomposition of business processes
    SOA-style interfaces perform a specific task
    “Process as a flowchart/workflow”
    Functional decomposition of business processes
  • 11. HTTP is an Application Protocol.
    REST recognises this.
  • 12. Remember the OSI Stack?
  • 13. This has a number of benefits…
  • 14. Reliable Communication
    (as long as the client knows how to handle errors and retries)
    Free* Caching!
    *provided by commodity infrastructure!
  • 15. Easy Metadata exchange via HTTP Headers!
  • 16. …and last but not least…
    A Universally-Understood Protocol!
  • 17. But How is that Better than SOAP?
  • 18. HTTP has Standard Verbs
  • 19. HTTP has Standard Verbs
    Standard Meaning
     Constraints = scope for optimization
    Widely Implemented
    Everybody knows how to behave
  • 20. SOAP Doesn’t.
    And everything works via HTTP POST
    (i.e. it uses HTTP as the dumb transport)
  • 21. HTTP has Standard Responses
    200 OK
    302 Moved Permanently
    404 Not Found
    406 Method Not Allowed
    409 Conflict
    418 I’m a Teapot

  • 22. SOAP Doesn’t.
  • 23. One last principle before we move on:
  • 24. One last principle before we move on:
  • 25. An Example
    Client requests Shopping Cart
    Server sends HTML page with items and links
    Client’s move
    Client clicks the “Check Out” link
    Server sends HTML page with Total Amount
    Client’s move
    Client clicks the “Pay” link
    Server sends HTML page with “Thank You” message
  • 26. Notice Something?
    The Client is responsible for moving forward in a process
    The server guides the client forward
    (with ‘Check Out’, ‘Pay’ links)
    The client is responsible for completing the process
    If the client stops, the server doesn’t care!
  • 27. Notice Something?
    The server doesn’t maintain session/application state.
    It does maintain resource state!
    Every request modifies the state of a resource
    In the example, the client causes the state of the “Shopping Cart” resource to be modified.
  • 28. Concepts
    Applications in SAP-land
  • 29. NetWeaver Gateway
  • 30. The Good Things
    Exposes BAPIs, RFCs & custom ABAP classes via OData XML
    Well integrated into SAP’s roadmap
    Tight integration with v2.1 of SUP – Sybase Unwired Platform
    Duet Enterprise
    Standard content and pre-built integration will be delivered by SAP
    Framework provides flexible security and auditing/logging
    Push notifications to consumers after subscription
    Expose data & functionality from older (pre-7.02) systems
  • 31. 2 Approaches to Development
    Generation Tools
    Complete Control
    Allows custom code adhering to a structured framework with a library ofhelper classes
    Quickly expose BAPIs, RFCs and GUI screens
    Up & running in minutes!
    OData Channel
  • 32. The Limitations
    Only supports OData (Open, but Microsoft-centric XML)
    no custom representations (other XML, JSON, PDF, etc.)*
    Limited support for complex input parameters*
    The Generation tools don’t:
    Allow modification of HTTP headers for caching, CORS, etc.
    Created linked resources (e.g. navigate Customer  Order  Item)
    Use of the OData Channel when developing Gateway Services makes this possible!
    *In development
    CORS is a method for working around browser-based cross-domain scripting security measures which can hamper JSON or AJAX-based browser applications.
  • 33. Mapping to a BAPI
    BAPI Field
    OData XML Field
  • 34.
  • 35.
  • 36. More Info on Gateway at TechEd
  • 37. Custom Development
  • 38. DJ Adams Started It All!
  • 39. A Simple RESTful API for SAP CRM
    BusinessPartners everywhere
    BPs have roles (e.g. Customer, Contact Person, Employee…)
    BPs have relationships with other BPs
    Relationships have attributes
    Relationships lead to Opportunities
    Target consumer: Mobile app built with HTML5 + jQuery Mobile
  • 40. 3 Resources
    plus any sub-resources we need
  • 41. Design Principles
    JSON as the default format
    Roles & Relationships via hyperlinks
    Client must only know the ‘entry point’ URL to its own BP
    All other client interaction driven by hyperlinks
    There is a great ABAP  JSON library on CodeExchange!
  • 42. Sidebar: Hyperlinks in JSON
  • 43. Sidebar: Hyperlinks in JSON
    No one standard to show hyperlinks
     We chose the simplest option we found:
    “links”: {
    “self”: “http://…”,
    “up”: “http://…”,
    “http://auspost.com.au/api/doc/rels/tracking”: “http://…”,

    magic keyword
    custom relationship
    link URL
    *as per IANA standard
  • 44. ICF Configuration in SAP CRM
    Create a public class
  • 45. ICF Configuration in SAP CRM
    Assign interface IF_HTTP_EXTENSION
  • 46. Insert Code Here…
  • 47.
  • 48.
  • 49.
  • 50.
  • 51. Demo
  • 52. Summary
    REST is an architectural style
    Apply web principles to A2A integration
    Promotes true loose coupling via hyperlinks
    Based on Resources rather than functionality or tasks
    NetWeaver Gateway can expose SAP data & functionality in a RESTful way.
    More specific requirements can be met with Z code
    Most mobile frameworks rely on RESTful integration
    But the REST style is equally valid for A2A and non-mobile scenarios!
  • 53. About Us
    John Moy
  • 54. Feedback
    Please complete a session evaluation for this session
    Session Code: MOB107
  • 55. Resources & Further Reading
    A free eBook on REST, by InfoQ: http://www.infoq.com/minibooks/emag-03-2010-rest
    Other interesting blogs and articles on InfoQ:
    The Richardson Maturity Model, explained by Martin Fowler: http://martinfowler.com/articles/richardsonMaturityModel.html
    ...and by Leonard Richardson himself: http://www.crummy.com/writing/speaking/2008-QCon/act3.html
    DJ Adams’ original blog on REST on SDN: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/584
    Further blogs by DJ on implementing RESTful services via the ICF:
    A Simple Intro to JSON: http://json.org
    CORS – Cross-Origin Resource Sharing, by the Mozilla Developer Network: http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/
  • 56. Resources & Further Reading
    The NetWeaver Gateway page on SDN: http://www.sdn.sap.com/irj/sdn/gateway
    How to Create Gateway Services Using the OData Channel API:
    Remote-Enabled Function Module to Gateway Service in 7 Minutes:
    Known Limitations of SAP NetWeaver Gateway: SAP Note 1574568
  • 57. Attributions
    Images by Geek & Poke (Oliver Widder):
    ‘Standards’ by xkcd (Randall Munroe): http://xkcd.com/927/
    ‘Permanent State’ by Gaping Void (Hugh MacLeod): http://gapingvoid.com/2011/07/28/permanent-state/
    Many thanks to all for providing their work under a Creative Commons license! 