Your SlideShare is downloading. ×
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.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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


Published on

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

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.
  • Transcript

    • 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://…”,

      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:
      Other interesting blogs and articles on InfoQ:
      The Richardson Maturity Model, explained by Martin Fowler:
      ...and by Leonard Richardson himself:
      DJ Adams’ original blog on REST on SDN:
      Further blogs by DJ on implementing RESTful services via the ICF:
      A Simple Intro to JSON:
      CORS – Cross-Origin Resource Sharing, by the Mozilla Developer Network:
    • 56. Resources & Further Reading
      The NetWeaver Gateway page on SDN:
      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):
      ‘Permanent State’ by Gaping Void (Hugh MacLeod):
      Many thanks to all for providing their work under a Creative Commons license! 