BEA Confidential. | 1

Building REST Service APIs for Rich Internet Applications

Peter LairdManaging ArchitectWebLogic PortalBEA Systems

Peter Laird

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