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

Server Access

The REST of the Story

David ClearyPrincipal Software EngineerJune 12, 2013

© 2013 Progress Software Corporation. All rights reserved.2

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

REST

Resource based

Lighter weight

Can use JSON or XML

Contract via documentation

SOAP

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


Scientific Approach to Choosing

21 Decisions and 64 alternativesREST Rules

The Cloud


Agenda




Demo


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


OpenEdge Reference Architecture

Presentation Enterprise Services

Business Components

Data Access

Data Sources

Com

mon Infrastructure

Workflow Task Entity


AutoEdge


OpenEdge REST Adapter

Machine AMachine B

Machine C

HTTP Web ServerOpenEdge Explorer /

OpenEdge ManagementOpenEdge Explorer /

OpenEdge Management

RESTMAN /command lineRESTMAN /command line

Java containerJava container

REST Management AgentREST Management Agent

REST Client #1 OpenEdge AppServerOpenEdge AppServerREST Application #1REST Application #1

OpenEdge AppServerOpenEdge AppServer

OpenEdge AppServerOpenEdge AppServer

REST Client #2

REST Client #3 REST Application #3REST Application #3

REST Application #2REST Application #2

Progress Developer Studio for OpenEdge

Progress Developer Studio for OpenEdge


Agenda




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




Demo


CRM Application

Resources

• Customers

• Orders

• CustomerOrders

Techniques used

• Hyperlinks (Locators)

• HTTP Response Code

• Multiple parameter bodies

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!

http://www.progress.com/exchange-pug

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

Documents

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