BEA Confidential. | 1 Building REST Service APIs for Rich Internet Applications Peter Laird Managing Architect WebLogic Portal BEA 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 

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 – 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", " 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  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   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 5Chapter 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. Joke: 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:  Bad:  Bad: 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:  XmlHttpRequest:  That XHR will fail

Peter Laird Thank You