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? 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

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.
  • REST: So What's It All About? (SAP TechEd 2011, MOB107)

    1. 1. REST – So What’s It All About?<br />MOB107 @ SAP TechEd 2011<br />Las Vegas<br />
    2. 2. Agenda<br />Concepts<br />Applications in SAP-land<br />Demo<br />
    3. 3. Agenda<br />Concepts<br />Applications in SAP-land<br />Demo<br />
    4. 4. REST<br />
    5. 5. REpresentationalStateTransfer<br />
    6. 6. What Does That Mean?<br />
    7. 7. The Client communicates with the Server by modifying the state of Resourcesthrough Representations<br />
    8. 8. Representations?<br />The server can store its data in whatever way it likes<br />The client is unaware of this, and can store the same things differently<br />Each party serialises its internal state into Representations<br />This provides loose coupling!<br />
    9. 9. Everything has a URL<br />
    10. 10. URLs Identify Resources<br />REST interfaces manipulate the state of resources<br />“Process as a state machine/data flow diagram”<br />Resource-oriented decomposition of business processes<br />SOA-style interfaces perform a specific task<br />“Process as a flowchart/workflow”<br />Functional decomposition of business processes<br />
    11. 11. HTTP is an Application Protocol.<br />REST recognises this.<br />
    12. 12. Remember the OSI Stack?<br />
    13. 13. This has a number of benefits…<br />
    14. 14. Reliable Communication<br />(as long as the client knows how to handle errors and retries)<br />Free* Caching!<br />*provided by commodity infrastructure! <br />
    15. 15. Easy Metadata exchange via HTTP Headers!<br />Accept<br />Content-Type<br />If-Modified-Since<br />Last-Modified<br />
    16. 16. …and last but not least…<br />A Universally-Understood Protocol!<br />
    17. 17. But How is that Better than SOAP?<br />
    18. 18. HTTP has Standard Verbs<br />GET<br />PUT<br />POST<br />DELETE<br />HEAD<br />OPTIONS<br />PATCH<br />TRACE<br />
    19. 19. HTTP has Standard Verbs<br />Standard Meaning<br /> Constraints = scope for optimization<br />Widely Implemented<br />Everybody knows how to behave<br />
    20. 20. SOAP Doesn’t.<br />getAccountCustomerByInternalId<br />searchCustomerByBasicData<br />updateSalesProspectStatusByPartnerSalesRepresentativeBasicData_sync<br />And everything works via HTTP POST<br />(i.e. it uses HTTP as the dumb transport)<br />
    21. 21. HTTP has Standard Responses<br />200 OK<br />302 Moved Permanently<br />404 Not Found<br />406 Method Not Allowed<br />409 Conflict<br />418 I’m a Teapot<br />…<br />
    22. 22. SOAP Doesn’t.<br />
    23. 23. One last principle before we move on:<br />HATEOAS<br />
    24. 24. One last principle before we move on:<br />Hypertext<br />As<br />The<br />Engine<br />Of<br />Application<br />State<br />
    25. 25. An Example<br />Client requests Shopping Cart<br />Server sends HTML page with items and links<br />Client’s move<br />Client clicks the “Check Out” link<br />Server sends HTML page with Total Amount<br />Client’s move<br />Client clicks the “Pay” link<br />Server sends HTML page with “Thank You” message<br />
    26. 26. Notice Something?<br />The Client is responsible for moving forward in a process<br />The server guides the client forward<br /> (with ‘Check Out’, ‘Pay’ links)<br />The client is responsible for completing the process<br /> If the client stops, the server doesn’t care!<br />
    27. 27. Notice Something?<br />The server doesn’t maintain session/application state.<br /> It does maintain resource state!<br />Every request modifies the state of a resource<br />In the example, the client causes the state of the “Shopping Cart” resource to be modified.<br />
    28. 28. Concepts<br />Applications in SAP-land<br />Demo<br />
    29. 29. NetWeaver Gateway<br />
    30. 30. The Good Things<br />Exposes BAPIs, RFCs & custom ABAP classes via OData XML<br />Well integrated into SAP’s roadmap<br />Tight integration with v2.1 of SUP – Sybase Unwired Platform<br />Duet Enterprise<br />Standard content and pre-built integration will be delivered by SAP<br />Framework provides flexible security and auditing/logging<br />Push notifications to consumers after subscription<br />Expose data & functionality from older (pre-7.02) systems<br />
    31. 31. 2 Approaches to Development<br />Generation Tools<br />Complete Control<br />Allows custom code adhering to a structured framework with a library ofhelper classes<br />Quickly expose BAPIs, RFCs and GUI screens<br />Up & running in minutes!<br />OData Channel<br />
    32. 32. The Limitations<br />Only supports OData (Open, but Microsoft-centric XML)<br />no custom representations (other XML, JSON, PDF, etc.)*<br />Limited support for complex input parameters*<br />The Generation tools don’t:<br />Allow modification of HTTP headers for caching, CORS, etc.<br />Created linked resources (e.g. navigate Customer  Order  Item)<br />Use of the OData Channel when developing Gateway Services makes this possible!<br />*In development<br />CORS is a method for working around browser-based cross-domain scripting security measures which can hamper JSON or AJAX-based browser applications. <br />
    33. 33. Mapping to a BAPI<br />BAPI Field<br />Defaults<br />OData XML Field<br />
    34. 34.
    35. 35.
    36. 36. More Info on Gateway at TechEd<br />
    37. 37. Custom Development<br />
    38. 38. DJ Adams Started It All!<br />
    39. 39. A Simple RESTful API for SAP CRM<br />BusinessPartners everywhere<br />BPs have roles (e.g. Customer, Contact Person, Employee…)<br />BPs have relationships with other BPs<br />Relationships have attributes<br />Relationships lead to Opportunities<br />Target consumer: Mobile app built with HTML5 + jQuery Mobile<br />
    40. 40. 3 Resources<br />http://sapcrm:8000/auspost/businesspartner<br />http://sapcrm:8000/auspost/bprelationship<br />http://sapcrm:8000/auspost/opportunity<br />plus any sub-resources we need<br />
    41. 41. Design Principles<br />JSON as the default format<br />Roles & Relationships via hyperlinks<br />Client must only know the ‘entry point’ URL to its own BP<br />All other client interaction driven by hyperlinks<br />There is a great ABAP  JSON library on CodeExchange!<br />
    42. 42. Sidebar: Hyperlinks in JSON<br />
    43. 43. Sidebar: Hyperlinks in JSON<br />No one standard to show hyperlinks<br /> We chose the simplest option we found:<br />“links”: {<br /> “self”: “http://…”,<br /> “up”: “http://…”,<br /> “”: “http://…”,<br /> …<br />}<br />magic keyword<br />relationship*<br />custom relationship<br />link URL<br />*as per IANA standard<br />
    44. 44. ICF Configuration in SAP CRM<br />Create a public class <br />
    45. 45. ICF Configuration in SAP CRM<br />Assign interface IF_HTTP_EXTENSION<br />
    46. 46. Insert Code Here…<br />
    47. 47.
    48. 48.
    49. 49.
    50. 50.
    51. 51. Demo<br />
    52. 52. Summary<br />REST is an architectural style<br />Apply web principles to A2A integration<br />Promotes true loose coupling via hyperlinks<br />Based on Resources rather than functionality or tasks <br />NetWeaver Gateway can expose SAP data & functionality in a RESTful way. <br />More specific requirements can be met with Z code<br />Most mobile frameworks rely on RESTful integration<br />But the REST style is equally valid for A2A and non-mobile scenarios!<br />
    53. 53. About Us<br />SaschaWenninger<br /><br />@sufw<br />John Moy<br /><br />@jhmoy<br />
    54. 54. Feedback<br />Please complete a session evaluation for this session<br />Session Code: MOB107<br />
    55. 55. Resources & Further Reading<br />A free eBook on REST, by InfoQ:<br />Other interesting blogs and articles on InfoQ:<br /><br />The Richardson Maturity Model, explained by Martin Fowler:<br /> ...and by Leonard Richardson himself:<br />DJ Adams’ original blog on REST on SDN:<br />Further blogs by DJ on implementing RESTful services via the ICF: <br /><br /><br /><br />A Simple Intro to JSON:<br />CORS – Cross-Origin Resource Sharing, by the Mozilla Developer Network:<br />
    56. 56. Resources & Further Reading<br />The NetWeaver Gateway page on SDN:<br />How to Create Gateway Services Using the OData Channel API:<br /><br />Remote-Enabled Function Module to Gateway Service in 7 Minutes:<br /><br />Known Limitations of SAP NetWeaver Gateway: SAP Note 1574568<br />
    57. 57. Attributions<br />Images by Geek & Poke (Oliver Widder):<br /><br /><br /><br />‘Standards’ by xkcd (Randall Munroe):<br />‘Permanent State’ by Gaping Void (Hugh MacLeod):<br />Many thanks to all for providing their work under a Creative Commons license! <br />