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

OE Mobile Tooling

Rest Adapter Tooling

OE Mobile Tooling

Rest Adapter Tooling

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

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

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

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

What is a Resource?

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

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.

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

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

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

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

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.

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.

AutoEdge

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

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

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

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

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

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

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

HTTP DELETE Deletes the resource identified on the server Also Idempotent

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

HTTP DELETE Deletes the resource identified on the server Also Idempotent

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

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

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

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

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

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

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!

Change color