Building REST Service APIs for Rich Internet Applications

Download Report

Transcript Building REST Service APIs for Rich Internet Applications

Building REST
Service APIs for
Rich Internet
Applications
Peter Laird
Managing Architect
WebLogic Portal
BEA Systems
BEA Confidential. | 1
About the Speaker
Has 10 years of server side Java development experience
Leads the architecture team for BEA WebLogic Portal, a
leading Java enterprise portal product

Has worked on WebLogic Portal for 7 years as a developer and
architect

WebLogic Portal introduced REST-like APIs in version 10.2
Holds the following certifications

Oracle DBA

Cisco CCNA
Regular contributor to BEA’s developer website

http://dev2dev.bea.com
Peter Laird
Housekeeping
This is a 30 Minute Presentation

A lot to cover, will move very fast

Will focus more on REST, less on RIA development
Assumes you have a basic understanding of:

HTTP

XML

JavaScript

A dynamic web programming technology (Java Servlets, .NET, PHP)
Peter Laird
Agenda
Rich Internet Applications (RIA)
Data Driven Rich Internet Applications
Principles of REST
REST in Practice
Peter Laird
Rich Internet Applications
Attributes of Rich Internet Applications (RIA)

Run in a browser, or do not require a software install

Supported with a server side component which holds application state

HTTP is used to communicate with the server

Client contains some basic processing capabilities

Have an interactive feel like a fat-client application
Technologies used to create RIAs

JavaScript and the XmlHttpRequest (Ajax)

Adobe Flash and Flex

Microsoft Silverlight

Laszlo, JavaFX, XUL, etc etc
Peter Laird
RIA: the New Web Standard
Think of the browser as a virtual machine

Not just a page rendering application

Programmable through JavaScript or plugins

HTTP networking support
RIAs becoming the standard of web applications

Netflix, Google Mail, etc started the trend

Now any noteworthy consumer facing web app is an RIA

Browser support for RIA is very good
Peter Laird
Data Driven Rich Internet Applications
Peter Laird
RIA: Data Driven
RIAs typically request data from a server

Netflix – movie catalog

Gmail – email messages
Often these requests are very fine grained
Requires an efficient mechanism for retrieving that data
RIA technologies universally provide an HTTP client

XmlHttpRequest for Ajax use cases

We will use Ajax in this presentation
Peter Laird
Ajax and XmlHttpRequest Sample
// create a request object
var xhr = new XMLHttpRequest();
// define the request properties
xhr.open("GET", "http://myURL/getJSON.jsp", true);
xhr.onreadystatechange = myHandler;
// define the callback handler
xhr.send(null);
// send the request
function myHandler()
// callback definition
{
if (xhr.readyState == 4)
// response has been received
{
if (xhr.status != 404)
{
var data=eval(‘(’ + xhr.responseText + ‘)’);
// invoke JS to manipulate the response
}
}
}
Peter Laird
WS-*
Web Services (WS-*) Standards are a valid approach

SOAP is an XML format for defining a service request and response
 I will use WS-* notation to refer to SOAP over HTTP
 WS-* also includes a number of subordinate standards
WS-Security
WS-Transaction
Etc
Proper deployment of a WS requires a WSDL to describe it

XML document that describes the Web Service and how to access it
WS-* is not a lightweight approach

Requires a good SOAP stack on the client, or
 Requires client code to create SOAP requests and parse the SOAP
response
Peter Laird
Introducing REST
Yes, there is a better way
REpresentational State Transfer (REST)

A simpler approach to building data services
REST services are implemented using the basics of the web

Service end points are resources http://host/api/content/myfolder

Return payload is usually simple plain text, JSON or XML structures
REST is a general approach for building services, but…

RIA development will likely be the first time you will use REST

Will focus exclusively on RIA use cases for REST in this talk
Peter Laird
REST Example: Search Suggestions
You want to have Google like suggestions in your search box
You have wired the search box with a JavaScript event
handler that uses an XmlHttpRequest to call the data service
The XmlHttpRequest callback expects a list of search
keywords in return

JavaScript populates the suggestion dropdown
How do you implement the REST service?
Peter Laird
REST Example: Search Suggestions Impl
Create a REST service on the server

Java: easily implemented using a Servlet or JSP
URLs used by Ajax will look like

http://host/searchengine/suggestions?text=“am”

Where “am” is the text the user has typed into the box
The service will respond with an HTTP response with the
following body:
amigo
america
ammunition
The JavaScript parses that list and populates the drop-down
Peter Laird
REST Real World: WebLogic Portal
Author was involved in a REST implementation for WebLogic
Portal (WLP)
WLP needed to implement dynamic UI features

Move portlets around on a page using drag and drop

Retrieve the list of portlets that can be added to a page

Choose from a list of available branding schemes for a page
JavaScript+XmlHttpRequest was the RIA technology chosen
WLP implemented a set of REST-like APIs

Not 100% REST compliant, but pretty close
Peter Laird
REST Real World: WebLogic Portal
Peter Laird
REST Principles
Peter Laird
Two REST References
Roy Fielding Dissertation

Origin of the idea

Focus on Chapter 5
RESTful Web Services book

Leonard Richardson and Sam Ruby

Recommended as a pragmatic guide

Not loved by all, search the internet to learn what the community thinks
about this book

Explains why the REST principles are important to follow
Peter Laird
Beware of the REST Nerd Wars
REST similar to Object Oriented design

Common to see arguments between pragmatists and purists

We had some of this during our WebLogic Portal implementation
Purists are known as the RESTafarians

Joke: Are RESTafarians clean? No, they don’t use any SOAP.
As with OO, there are some core principles but also a lot of
opinion and style

You will need to formulate your own style
Peter Laird
URL Represents a Noun, not a Verb
REST services are based on Resources not Operations

Use Case: URL for a service that returns a list of addresses

Good: http://host/cities/colorado/denver/

Bad:
http://host/addresses/getlist?city=denver

Bad:
http://host/addresses?op=getlist&city=denver
Guidelines:

URLs should express a noun, not a verb

URL path should illustrate a logical structure of the resources

URL parameters are used to feed modifiers into an algorithm
Peter Laird
HTTP Verb Matters
REST services should honor the HTTP method (verb)

GET –reads the state of a resource described by the URL

PUT – adds the resource described by the URL

DELETE – deletes the resource described by the URL

POST – updates the resource described by the URL
Guidelines:

Do not embed the verb in the URL path or query parameters

GET must not alter the state of the server

GET, PUT and DELETE must be idempotent
Peter Laird
HTTP Response Codes
REST services should use the proper HTTP response codes

200 – request was properly understood, the operation succeeded

400 – the client sent an invalid request

500 – internal server error, there is a problem on the server

404 – the URL does not map to a valid resource

401 – not authorized
Guidelines:

Anti-pattern is to always return 200, and embed the result of the
operation in the response body
Peter Laird
REST in Practice
Peter Laird
JSON as the Return Payload
XML is a safe format to return from the REST service

But not the easiest when the client is JavaScript
JavaScript Object Notation (JSON) is usually a better
alternative when the client will always be JavaScript
One line reconstitutes the returned structure into a native
JavaScript object

var payload = eval(‘(’ + xhr.responseText + ‘)’);
Peter Laird
Authenticaton
Many REST services will require authentication
Usually “just works” for Ajax RIA applications

User logs into the application

XmlHttpRequests carry the session cookies to the server

REST services will recognize the user session
Two easy solutions for explicit authentication for REST

HTTP Basic authentication

Custom authentication REST service

Make sure HTTPS is used for transport!
Two harder solutions for explicity authentication

Digest

WSSE
Peter Laird
Single Origin Policy
This issue affects any XmlHttpRequest
XmlHttpRequest cannot target a network domain different
from the outer page
This is a security feature, but will affect how you deploy your
REST services
Example:

Outer page: http://mygoodhost.com/theAjaxPage.jsp

XmlHttpRequest: http://evil.com/stealCookies.jsp

That XHR will fail
Peter Laird
Thank You
Peter Laird