Introduction to REST and the Restlet Framework


Published on

A brief introduction to the Representational State Transfer (REST) architectural paradigm and a walkthrough of a Restlet sample application.

  • Be the first to comment

Introduction to REST and the Restlet Framework

  1. 1. Introduction to Representational State Transfer (REST) and the Restlet Framework Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii
  2. 2. Agenda Concepts: Why REST? REST principles What is Restlet? Restlet-DateService: Download distribution Command line usage build.xml The server-side code The client-side code JUnit tests + Jacoco Building the jars
  3. 3. Why REST? The web according to most webapp frameworks: Wicket, RoR, etc all designed for human-computer interaction. (as well as AJAX, CSS, HTML, Fonts, JQuery, Javascript, etc.) Server Server Server Server
  4. 4. Why REST? But there is another kind of interaction: Most HCI mechanisms are not well-designed for computer-computer interaction. Server Server Server Server
  5. 5. Why REST? Computer-Computer interaction can be very powerful: Provide “mashups” of data from different sources. Support automated crawling of the web (i.e. Google) Realize the full potential of the web. But to do this, we need a way for computers to easily and expressively communicate with each other.
  6. 6. REST Representational State Transfer (REST) is an “architectural style” defined by Roy Fielding. The concepts of REST are independent of the web, but the web is well-suited to REST. Simplistically, a “RESTful architecture” includes: Resources (things) with Unique ids (URLS) that can come in many Representations (text, html, json) that you operate on with Verbs (GET, PUT, DELETE, POST)
  7. 7. REST in a nutshell URLs must name resources. They are nouns: Not verbs: Use operators (verbs) such as GET, PUT, POST, DELETE to operate on resources (nouns): GET PUT POST DELETE
  8. 8. REST in a nutshell Most common operators (verbs): GET: retrieve a representation of a resource (without changing it). PUT: create or replace a resource by supplying a representation of it. DELETE: ensure that a given resource is no longer present. POST: augment a resource with additional information by supplying a representation of that info.
  9. 9. REST in a nutshell Representations As an external user, you cannot manipulate resources directly. Instead, you manipulate “representations” of that resource. Many people can “get” a representation of a single resource. The same resource can be represented in many different ways.
  10. 10. The web and REST The web’s primary protocol (HTTP) is tailor-made for RESTful architectures. Unique IDs for resources (URIs) Verbs (HTTP operators) Multiple representations (Media types) But many (most) web applications do not implement REST! Use of GET for everything. URLs that indicate actions, not things. Many other subtle ways to violate REST. See readings for more details.
  11. 11. REST is best for computer-computer interaction The jury is still out on whether REST is always best for human-computer interaction. Server Server Server Server
  12. 12. Restlet A Java framework for implementing REST systems. Operators, Resources, Representations, are all “first class” entities in Restlet. Highly “pluggable” implementation to support extensibility and interfaces to other web technologies Atom, Freemarker, GWT, JAAS, Jackson, JavaMail, JAXB, Jetty, JSON, Lucene, OData, RDF, Rome, Spring, WADL, SSL, XML, etc.
  13. 13. Restlet-DateService A “hello world II” Restlet application Simple to install and run Illustrates basic RESTful client and server using Restlet. Shows unit testing with JUnit. Packaging of client and server into jars. Does not show: PUT, POST, DELETE operators. Authorization and authentication. Templates URLs. Restlet extensions Automatic media type negotiation