1. Server Access The REST of the Story David Cleary
Principal Software Engineer
June 12, 2013

2. OE Mobile Tooling

3. Rest Adapter Tooling

4. OE Mobile Tooling

5. Rest Adapter Tooling

6. Agenda Why REST? REST Architectural Overview
What is RESTful in the Progress World
RESTing your Progress Servers
Demo

7. Key Takeaways Understanding of RESTful Application Principals
Knowing when to REST or not
What OpenEdge provides in 11.2 and later to REST

8. Architecture or Protocol?
HTTP
HyperText Transfer Protocol
Defines text-based message format and exchange protocol
Foundation for communications in the cloud
SOAP
Simple Object Access Protocol
Defines an XML-based message format and exchange protocol
Specifies bindings to HTTP and other transports
REST
Representational State Transfer
Style of software architecture for distributed systems
Describes the architecture of HTTP
Predominate web API design model

9. REST Architecture There is no REST Specification
REST does not define a message format
REST does not define a message exchange protocol
REST is stateless
Each client request contains all the information to service the request
REST is resource-based
Resources are identified by URI (Uniform Resource Identifier)
Server provides a representation of resource to client
Client can manipulate resource on server through the representation
CRUD Model
Create, Read, Update and Delete

10. What is a Resource?

11. REST Web Services Uses HTTP as its protocol
Resource identification through URI
Uniform interface (GET, PUT, POST, DELETE)
Typically uses JSON or XML as message format
Every interaction with a resource is stateless

12. RESTful Web Services vs. SOAP
Resource based
Lighter weight
Can use JSON or XML
Contract via documentation
Procedural
Contains more details
Uses XML
Contract via WSDL
When to use SOAP
Intranet applications – More mature tooling
B2B applications – Strong contract
Exposing existing applications
When to use REST
Cloud-based and mobile applications
Creating highly scalable stateless applications
For Progress, the decision to add support for REST Web services in OpenEdge was made based on industry trends.
For example, REST is the most common way to make Web service calls to cloud based applications.
The obvious question is why has REST become the protocol of choice when sending and receiving data be between clients and cloud based services.
One answer is low overhead and simplicity.
Just to focus on a few areas ….
The SOAP protocol provides an interface that can be though of as procedural and utilizes XML to send and receive information. Data types can be defined in SOAP indicating how to interpret the data.
REST, on the other hand, - is resource based, relying in a URI to locate a resource.
OpenEdge REST utilizes - the JSON format to transmit data.
JSON uses name and value pairs for all data.
This simpler protocol - reduces the amount of data that needs to be sent over the wire, resulting in improved network performance.
Note:
The difference: SOAP is transport neutral, while REST is tied tightly to HTTP.    SOAP is only XML, and REST can be any media type.
SOAP uses formal interface definitions (WSDL) while REST does not (WADL is not enough yet to qualify)
The choice: 
Use SOAP for B2B where an agreed contract (WSDL) is versioned and must be met by all parties.   
Use REST where agreement is less firm between clients and the provider.

13. Scientific Approach to Choosing
REST Rules
The Cloud
21 Decisions and 64 alternatives
WWW2008
©2008 Cesare Pautasso

14. Scientific Approach to Choosing
REST Rules
The Cloud
21 Decisions and 64 alternatives
WWW2008
©2008 Cesare Pautasso

15. Agenda Why REST? REST Architectural Overview
What is RESTful in the Progress World
RESTing your Progress Servers
Demo

16. Progress REST Support WebSpeed OpenEdge Reference Architecture (OERA)
Supporting RESTful applications since 1997
No tooling support specific to REST – Developer must do everything
OpenEdge Reference Architecture (OERA)
Business Entities are resources
AutoEdge a RESTful application
OpenEdge REST Adapter
Delivered as part of OpenEdge 11.2
Progress DataDirect Cloud

17. OpenEdge Reference Architecture
Presentation
Enterprise Services
Business Components
Data Access
Data Sources
Common Infrastructure
Workflow
Task
Entity
Speaking of the OERA …. What is it?
The OpenEdge Reference Architecture (OERA) defines the general functional categories of components that comprise an application. It can be used as a high-level blueprint for developing OpenEdge service-oriented business applications.
Each layer of the OERA consists of distinct components, each with specific characteristics, roles and responsibilities. In addition, the OERA provides guidelines as to how each of the architectural components interacts. The diagram shows these, and while it may seem complicated, the purpose of it is to simplify things: how the investment of breaking up the operation into different functional layers can benefit and simplify your application development.
In addition, one of the nice things about using a layered approach is that you can make a slow transformation to a layered application, and once there, change parts out without requiring wholesale changes to your application.

18. OpenEdge Reference Architecture
Presentation
Enterprise Services
Business Components
Data Access
Data Sources
Common Infrastructure
Workflow
Task
Entity
Speaking of the OERA …. What is it?
The OpenEdge Reference Architecture (OERA) defines the general functional categories of components that comprise an application. It can be used as a high-level blueprint for developing OpenEdge service-oriented business applications.
Each layer of the OERA consists of distinct components, each with specific characteristics, roles and responsibilities. In addition, the OERA provides guidelines as to how each of the architectural components interacts. The diagram shows these, and while it may seem complicated, the purpose of it is to simplify things: how the investment of breaking up the operation into different functional layers can benefit and simplify your application development.
In addition, one of the nice things about using a layered approach is that you can make a slow transformation to a layered application, and once there, change parts out without requiring wholesale changes to your application.

19. AutoEdge

20. OpenEdge REST Adapter Machine B Progress Developer Studio for OpenEdge
Machine A
HTTP Web Server
OpenEdge Explorer / OpenEdge Management
Java container
RESTMAN /command line
REST Management Agent
Machine C
REST Client #1
REST Application #1
OpenEdge AppServer
REST Client #2
REST Application #2
OpenEdge AppServer
REST Client #3
REST Application #3
OpenEdge AppServer

21. Agenda Why REST? REST Architectural Overview
What is RESTful in the Progress World
RESTing your Progress Servers
Demo

22. Applications and Services
Service - A collection of operations on a set of resources
Create – Create a new resource
Read – Retrieve an existing resource
Update – Update an existing resource
Delete – Delete an existing resource
An OpenEdge REST Application supports one or more services
Compiled into a Java WAR file

23. The URL Space
Protocol: HTTP
DNS System Name: api-public.netflix.com
Service Name: catalog
Resource Name: titles
URL Parameters: term=Ironman
Additional information required
HTTP Verb (GET, PUT, POST, and DELETE)
Optional body
Media type

24. HTTP GET Retrieves a resource or resource locators identified by a URL
Client identifies what media type[s] it wants via Accept header
application/json only type supported currently by OpenEdge
Input parameters specified in URL
Path parameters
URL Parameters
Additional parameter support
HTTP Headers
Additional metadata from request context
Does not support sending a body

25. HTTP POST Creates a new resource on server
Typically uses URL of parent resource
Requires a body that represents resource
OpenEdge limited to application/json
Can support path and URL parameters
OpenEdge supports mapping individual parameters extracted from a JSON body
Returns representation of new resource if accepted by the server

26. HTTP PUT Updates an existing resource on server
Uses URL of resource, unlike POST
Can create new resource at location specified by client, but not recommended
Idempotent – Identical requests have same effect as a single request

27. HTTP DELETE Deletes the resource identified on the server
Also Idempotent

28. Message Bodies Bodies must be JSON
Map TempTables and Datasets directly to bodies
Map CHARACTER and LONGCHARS to bodies
Custom JSON objects
Multiple parameters in body supported by request and response objects
Input parameters extracted and passed to AppServer
Output parameters added to response object
Only one level deep

29. HTTP DELETE Deletes the resource identified on the server
Also Idempotent

30. Message Bodies Bodies must be JSON
Map TempTables and Datasets directly to bodies
Map CHARACTER and LONGCHARS to bodies
Custom JSON objects
Multiple parameters in body supported by request and response objects
Input parameters extracted and passed to AppServer
Output parameters added to response object
Only one level deep

31. Service Interfaces Identify the entities you want to expose
Map these entities to your URL space
Determine what CRUD operations are applicable to what resources
Document the representation of your resources
Avoid verbs, but not at the cost of complexity

32. Sessions and Identity Management
Authentication, Authorization, and Session Management done at Web Server
Uses Spring Security Framework 3.1
Supports internal and external authentication providers
For production, you want stateful sessions
Web Server sessions, not AppServer
Done through JSESSIONID cookie
Must use AppServer SSO if you want identity on AppServer
Spring creates sealed ClientPrincipal

33. Agenda Why REST? REST Architectural Overview
What is RESTful in the Progress World
RESTing your Progress Servers
Demo

34. CRM Application Resources Techniques used Customers Orders
CustomerOrders
Techniques used
Hyperlinks (Locators)
HTTP Response Code
Multiple parameter bodies

35. CRM Application Resources Techniques used Customers Orders
CustomerOrders
Techniques used
Hyperlinks (Locators)
HTTP Response Code
Multiple parameter bodies

36. www.progress.com/exchange-pug October 6–9, 2013 • Boston #PRGS13
Special low rate of $495 for PUG Challenge attendees with the code PUGAM
And visit the Progress booth to learn more about the Progress App Dev Challenge!

37. Change color