1. GW100 SAP NetWeaver Gateway
Introduction to REST
May, 2012
INTE
RNA
L

2. Objectives
At the end of this chapter, you will understand:
Ÿ What Representational State Transfer (REST) is
Ÿ How REST has been implemented as HTTP(S)
© 2012 SAP AG. All rights reserved. 2

3. Agenda
u REST – The Foundational Principles of the World Wide Web
u HTTP – An Implementation of the Principles of REST
© 2012 SAP AG. All rights reserved. 3

4. Agenda
u REST – The Foundational Principles of the World Wide Web
u HTTP – An Implementation of the Principles of REST
© 2012 SAP AG. All rights reserved. 4

5. Correcting A Common Misunderstanding
So, Representational State Transfer
(REST) is some kind of network
protocol like HTTP or SOAP?
NO! REST is a design philosophy that defines six
architectural constraints.
These constraints govern the large-scale behaviour of
the participants within in a networked software system.
Any software system that conforms to the constraints of REST, is said to be RESTful.
The World Wide Web is the most prominent example of a software system that fully
implements the principles of REST.
© 2012 SAP AG. All rights reserved. 5

6. REST: A Software Design Philosophy – 1/6
REST defines 6 architectural constraints:
Communication between participants must:
1) Implement the Client-Server model
The client-server model allows for the client and server software components to be
developed independently.
It further assumes that the client will take no part in long-term data storage and that
the server will take no part in the presentation of the data it supplies.
This principle is known as the “Separation of Concerns”.
© 2012 SAP AG. All rights reserved. 6

7. REST: A Software Design Philosophy – 2/6
REST defines 6 architectural constraints:
Communication between participants must:
2) Be layered
When the client communicates with a server, it should not ordinarily be able to
distinguish whether it has communicated with the actual end-point server that will
supply the requested information, or some intermediate server used for system
scalability or security.
© 2012 SAP AG. All rights reserved. 7

8. REST: A Software Design Philosophy – 3/6
REST defines 6 architectural constraints:
Communication between participants must:
3) Be stateless
A stateless interface requires the client to supply all the necessary information for
the server to process the request.
Session information must be held on the client.
There is no prohibition against the server holding client state information, only that
the state information must be known to, and addressable by the client.
© 2012 SAP AG. All rights reserved. 8

9. REST: A Software Design Philosophy – 4/6
REST defines 6 architectural constraints:
Communication between participants must:
4) Be Uniform (meaning that)
a. The server must provide the client with a representation of its resources
b. A means must be provided for the client to manipulate those resources (E.G. Provide
operations such as Create, Read, Update, Delete etc)
c. All responses sent to the client must be self-describing
d. The manipulation of server-side resources may only be performed by hypermedia
supplied by the server.*
This constraint is generally regarded as the core concept of REST.
A server exposes a self-describing resource that can
be manipulated by a client via a hypermedia link.
* Known as “Hypermedia as the Engine of Application State” or HATEOAS. Remember this principle
because it is key to the success of OData!
© 2012 SAP AG. All rights reserved. 9

10. REST: A Software Design Philosophy – 5/6
REST defines 6 architectural constraints:
5) Server responses must define whether or not they are Cacheable
Response
caching
In order to improve performance and scalability, any information supplied by the
server must carry with it an indicator to denote whether or not it can be cached for
future use.
Any system within the layered architecture could act as a cache.
© 2012 SAP AG. All rights reserved. 10

11. REST: A Software Design Philosophy – 6/6
REST defines 6 architectural constraints:
6) The Server should be able to deliver Code-On-Demand to the client
At the request of the client, the server should be able to supply additional
executable code to extend the client’s capabilities.
This principle is used every time a browser requests a JavaScript file from a
webserver.
© 2012 SAP AG. All rights reserved. 11

12. Agenda
u REST – The Foundational Principles of the World Wide Web
u HTTP – An Implementation of the Principles of REST
© 2012 SAP AG. All rights reserved. 12

13. HTTP(S) – An Implementation of the REST Constraints
HTTP(S) is the Protocol that Drives the World Wide Web
A server-side resource can be manipulated in 4 basic ways.
These four basic REST operations have given rise the the acronym CRUD.
REST Operation HTTP Method
Create a resource POST
Retrieve one or more resources GET
Update a resource PUT
Delete a resource DELETE
HTTP(S) implements server-side resource manipulation by providing a set of
“Methods” that correspond to REST operations.
© 2012 SAP AG. All rights reserved. 13

14. Summary
u REST is a set of 6 design constraints, not a network protocol.
u The REST design constraints are fully implemented by the HTTP
protocol.
u The World Wide Web is an example of a fully RESTful software system.
u Just because an application protocol makes use of HTTP, does not
guarantee it to be RESTful!
© 2012 SAP AG. All rights reserved. 14

15. © 2012 SAP AG. All rights reserved
No part of this publication may be reproduced or transmitted in any form or for any purpose Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal
without the express permission of SAP AG. The information contained herein may be Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services
changed without prior notice. mentioned herein as well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP company.
Some software products marketed by SAP AG and its distributors contain proprietary
software components of other software vendors. Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft products and services mentioned herein as well as their respective logos are trademarks or
registered trademarks of Sybase, Inc. Sybase is an SAP company.
Corporation.
All other product and service names mentioned are the trademarks of their respective
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x,
companies. Data contained in this document serves informational purposes only. National
System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/
product specifications may vary.
VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server,
PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, The information in this document is proprietary to SAP. No part of this document may be
OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, reproduced, copied, or transmitted in any form or for any purpose without the express prior
RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent written permission of SAP AG.
Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of This document is a preliminary version and not subject to your license agreement or any
IBM Corporation. other agreement with SAP. This document contains only intended strategies, developments,
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. and functionalities of the SAP® product and is not intended to be binding upon SAP to any
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered particular course of business, product strategy, and/or development. Please note that this
document is subject to change and may be changed by SAP at any time without notice.
trademarks of Adobe Systems Incorporated in the United States and/or other countries.
SAP assumes no responsibility for errors or omissions in this document. SAP does not
Oracle is a registered trademark of Oracle Corporation.
warrant the accuracy or completeness of the information, text, graphics, links, or other items
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. contained within this material. This document is provided without a warranty of any kind,
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are either express or implied, including but not limited to the implied warranties of
trademarks or registered trademarks of Citrix Systems, Inc. merchantability, fitness for a particular purpose, or non-infringement.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World SAP shall have no liability for damages of any kind including without limitation direct, special,
Wide Web Consortium, Massachusetts Institute of Technology. indirect, or consequential damages that may result from the use of these materials. This
limitation shall not apply in cases of intent or gross negligence.
Java is a registered trademark of Sun Microsystems, Inc.
The statutory liability for personal injury and defective products is not affected. SAP has no
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for control over the information that you may access through the use of hot links contained in
technology invented and implemented by Netscape. these materials and does not endorse your use of third-party Web pages nor provide any
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, warranty whatsoever relating to third-party Web pages.
StreamWork, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and other
countries.
© 2012 SAP AG. All rights reserved. 15