Server Access
The REST of the Story
David Cleary
Principal Software Engineer
June 12, 2013
OE Mobile Tooling
2
© 2013 Progress Software Corporation. All rights reserved.
Rest Adapter Tooling
3
© 2013 Progress Software Corporation. All rights reserved.
OE Mobile Tooling
4
© 2013 Progress Software Corporation. All rights reserved.
Rest Adapter Tooling
5
© 2013 Progress Software Corporation. All rights reserved.
Agenda
 Why REST? REST Architectural Overview
 What is RESTful in the Progress World
 RESTing your Progress Servers
 Demo
6
© 2013 Progress Software Corporation. All rights reserved.
Key Takeaways
 Understanding of RESTful Application Principals
 Knowing when to REST or not
 What OpenEdge provides in 11.2 and later to REST
7
© 2013 Progress Software Corporation. All rights reserved.
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
8
© 2013 Progress Software Corporation. All rights reserved.
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
9
© 2013 Progress Software Corporation. All rights reserved.
What is a Resource?
10
© 2013 Progress Software Corporation. All rights reserved.
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
11
© 2013 Progress Software Corporation. All rights reserved.
RESTful Web Services vs. SOAP
REST
SOAP
 Resource based
 Procedural
 Lighter weight
 Contains more details
 Can use JSON or XML
 Uses XML
 Contract via
documentation
 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
12
© 2013 Progress Software Corporation. All rights reserved.
Scientific Approach to Choosing
13
© 2013 Progress Software Corporation. All rights reserved.
Scientific Approach to Choosing
14
© 2013 Progress Software Corporation. All rights reserved.
Agenda
 Why REST? REST Architectural Overview
 What is RESTful in the Progress World
 RESTing your Progress Servers
 Demo
15
© 2013 Progress Software Corporation. All rights reserved.
Progress REST Support
 WebSpeed
• 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
16
© 2013 Progress Software Corporation. All rights reserved.
OpenEdge Reference Architecture
Enterprise Services
Business Components
Task
Workflow
Data Access
Data Sources
17
© 2013 Progress Software Corporation. All rights reserved.
Entity
Common Infrastructure
Presentation
OpenEdge Reference Architecture
Enterprise Services
Business Components
Task
Workflow
Data Access
Data Sources
18
© 2013 Progress Software Corporation. All rights reserved.
Entity
Common Infrastructure
Presentation
AutoEdge
19
© 2013 Progress Software Corporation. All rights reserved.
OpenEdge REST Adapter
Machine B
Machine A
OpenEdge Explorer /
OpenEdge Management
HTTP Web Server
Java container
Progress
Developer
Studio for
OpenEdge
RESTMAN /command line
REST Management Agent
Machine C
20
REST Client #1
REST Application #1
OpenEdge
AppServer
REST Client #2
REST Application #2
OpenEdge
AppServer
REST Client #3
REST Application #3
OpenEdge
AppServer
© 2013 Progress Software Corporation. All rights reserved.
Agenda
 Why REST? REST Architectural Overview
 What is RESTful in the Progress World
 RESTing your Progress Servers
 Demo
21
© 2013 Progress Software Corporation. All rights reserved.
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
22
© 2013 Progress Software Corporation. All rights reserved.
The URL Space
 http://api-public.netflix.com/catalog/titles?term=Ironman
• Protocol: HTTP
• DNS System Name: api-public.netflix.com
• Service Name: catalog
• Resource Name: titles
• URL Parameters: term=Ironman
 http://localhost:8980/Application/rest/Service/Resource
 Additional information required
• HTTP Verb (GET, PUT, POST, and DELETE)
• Optional body
• Media type
23
© 2013 Progress Software Corporation. All rights reserved.
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
24
© 2013 Progress Software Corporation. All rights reserved.
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
25
© 2013 Progress Software Corporation. All rights reserved.
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
26
© 2013 Progress Software Corporation. All rights reserved.
HTTP DELETE
 Deletes the resource identified on the server
 Also Idempotent
27
© 2013 Progress Software Corporation. All rights reserved.
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
28
© 2013 Progress Software Corporation. All rights reserved.
HTTP DELETE
 Deletes the resource identified on the server
 Also Idempotent
29
© 2013 Progress Software Corporation. All rights reserved.
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
30
© 2013 Progress Software Corporation. All rights reserved.
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
31
© 2013 Progress Software Corporation. All rights reserved.
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
32
© 2013 Progress Software Corporation. All rights reserved.
Agenda
 Why REST? REST Architectural Overview
 What is RESTful in the Progress World
 RESTing your Progress Servers
 Demo
33
© 2013 Progress Software Corporation. All rights reserved.
CRM Application
 Resources
• Customers
• Orders
• CustomerOrders
 Techniques used
• Hyperlinks (Locators)
• HTTP Response Code
• Multiple parameter bodies
34
© 2013 Progress Software Corporation. All rights reserved.
CRM Application
 Resources
• Customers
• Orders
• CustomerOrders
 Techniques used
• Hyperlinks (Locators)
• HTTP Response Code
• Multiple parameter bodies
35
© 2013 Progress Software Corporation. All rights reserved.
October 6–9, 2013 • Boston
#PRGS13
www.progress.com/exchange-pug
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!