REST: So What's It All About? (SAP TechEd 2011, MOB107)
•Als PPTX, PDF herunterladen•
8 gefällt mir•3,724 views
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!
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (9)
Ähnlich wie REST: So What's It All About? (SAP TechEd 2011, MOB107)
Ähnlich wie REST: So What's It All About? (SAP TechEd 2011, MOB107) (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
REST: So What's It All About? (SAP TechEd 2011, MOB107)
- 1. REST – So What’s It All About? MOB107 @ SAP TechEd 2011 Las Vegas
- 2. Agenda Concepts Applications in SAP-land Demo
- 3. Agenda Concepts Applications in SAP-land Demo
- 4. REST
- 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! Accept Content-Type If-Modified-Since Last-Modified
- 16. …and last but not least… A Universally-Understood Protocol!
- 17. But How is that Better than SOAP?
- 18. HTTP has Standard Verbs GET PUT POST DELETE HEAD OPTIONS PATCH TRACE
- 19. HTTP has Standard Verbs Standard Meaning Constraints = scope for optimization Widely Implemented Everybody knows how to behave
- 20. SOAP Doesn’t. getAccountCustomerByInternalId searchCustomerByBasicData updateSalesProspectStatusByPartnerSalesRepresentativeBasicData_sync 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: HATEOAS
- 24. One last principle before we move on: Hypertext As The Engine Of Application State
- 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 Demo
- 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 Defaults OData XML Field
- 36. More Info on Gateway at TechEd
- 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 http://sapcrm:8000/auspost/businesspartner http://sapcrm:8000/auspost/bprelationship http://sapcrm:8000/auspost/opportunity 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 relationship* 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
- 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 SaschaWenninger sascha.wenninger@auspost.com.au @sufw John Moy john.moy@auspost.com.au @jhmoy
- 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: http://www.infoq.com/articles/RESTSOAFuture 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: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/15899 http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/17375 http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16014 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: http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/90f79f1c-d274-2e10-be9e-9dbffea99a5d Remote-Enabled Function Module to Gateway Service in 7 Minutes: http://www.sdn.sap.com/irj/scn/elearn?rid=/library/uuid/a016451c-f47e-2e10-febe-ec719fe62e4f Known Limitations of SAP NetWeaver Gateway: SAP Note 1574568
- 57. Attributions Images by Geek & Poke (Oliver Widder): http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0133f3e30a99970b-pi http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0105362b2664970c-pi http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef015390312d9f970b-pi ‘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!
Hinweis der Redaktion
- 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.