RESTful Web services

Resource-Oriented What Now?

Why come up with a new term, Resource-Oriented Architecture? Why not just say REST? Well, I do say REST, on the cover of this book, and I hold that everything in the Resource-Oriented Architecture is also RESTful. But REST is not an architecture: it’s a set of design criteria. You can say that one architecture meets those criteria better than another, but there is no one “REST architecture.”

Up to now, people have tended to mint one-off architectures as they design their services, according to their own understandings of REST. The most obvious outcome of this is the wide variety of REST-RPC hybrid web services that their creators claim are RESTful. I’m trying to put a stop to that by presenting a set of concrete rules for building web services that really will be RESTful. In the next two chapters I’ll even show simple procedures you can follow to turn requirements into resources. If you don’t like my rules, you’ll at least have an idea of what you can change and stay RESTful.

As a set of design criteria, REST is very general. In particular, it’s not tied to the Web. Nothing about REST depends on the mechanics of HTTP or the structure of URIs. But I’m talking about web services, so I explicitly tie the Resource-Oriented Architecture to the technologies of the Web. I want to talk about how to do REST with HTTP and URIs, in specific programming languages. If the future produces RESTful architectures that don’t run on top of the Web, their best practices will probably look similar to the ROA, but the details will be different. We’ll cross that bridge when we come to it

INTRODUCTION TO REST

•Representational State Transfer (REST) is an architectural style for the service of web

•The REST is used as a basis for HTTP 1.1 development

•Thus the WWW including servers, proxies, etc…

•REST is resource-based

• Focuses on Representations (of data/information/resources)

•Derived using Six Constraints

RESOURCE-BASED:

•Things vs Actions

•Nouns vs Verbs

•Identified by URIs

•Multiple URIs may refers to same resource

• But different according to the HTTP verb used (as like CRUD operation on same student resource)

•Separate from their representations

•Resource may be represented as request content type either JSON or XML etc.

REPRESENTATIONS:

•How resources get manipulated and presented

•Part of the resource state is transferred between client and server

•Typically JSON or XML

•Or even can be a web page, file, image, etc…

•E.g. The state of a student (as per the database) can be represented by a resource of webpage, XML

dataset, etc…

CONSTRAINTS:

1) Client-server

• The REST is for explicitly for networked distributed systems, which are based on the client-server style

2) Layered System

• A client doesn’t need to know whether it is connected directly to the end server, or to an intermediary along the way.

• Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches.

• Layers may also enforce security policies.

3) Stateless

• One client can send multiple requests to the server

• each request is independent

• every request must contain all the necessary information so that the server can understand it and process it accordingly.

• the server must not hold any information about the client state.

• Any state information must stay on client – such as sessions.

4) Cacheable

• As many clients access the same server, often they may request the same resources

• it is necessary that these responses might be cached, avoiding unnecessary processing, which may affect performance

5) Code-On-Demand (Optional)

• This allows the customer to run some code on demand, that is, extend part of server logic to the client, either through an applet or scripts.

6) Uniform Interface

•defines the interface between clients and servers.

• It simplifies and decouples the architecture, which enables each part to evolve independently

• REST is defined by four interface constraints:

• identification of resources

• manipulation of resources through representations

• self-descriptive messages

• hypermedia as the engine of application state

ELEMENTS OF REST STYLE

•Software that interacts with one another

•Communicate by transferring representations of resources through a standard interface

rather than operating directly upon there source itself

•Used to access, provide access to, or mediate access to resources

RESTful web services using RESTful URLs

RESTful web services are built to work best on the Web. Representational State Transfer (REST) is an architectural style that specifies constraints, such as the uniform interface, that if applied to a web service induce desirable properties, such as performance, scalability, and modifiability, that enable services to work best on the Web. In the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links on the Web. The resources are acted upon by using a set of simple, well-defined operations. The REST architectural style constrains an architecture to a client/server architecture and is designed to use a stateless communication protocol, typically HTTP. In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol.

The following principles encourage RESTful applications to be simple, lightweight, and fast:

Resource identification through URI: A RESTful web service exposes a set of resources that identify the targets of the interaction with its clients. Resources are identified by URIs, which provide a global addressing space for resource and service discovery. See The @Path Annotation and URI Path Templates for more information.

Uniform interface: Resources are manipulated using a fixed set of four create, read, update, delete operations: PUT, GET, POST, and DELETE. PUT creates a new resource, which can be then deleted by using DELETE. GET retrieves the current state of a resource in some representation. POST transfers a new state onto a resource. See Responding to HTTP Methods and Requests for more information.

Self-descriptive messages: Resources are decoupled from their representation so that their content can be accessed in a variety of formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others. Metadata about the resource is available and used, for example, to control caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access control. See Responding to HTTP Methods and Requests and Using Entity Providers to Map HTTP Response and Request Entity Bodies for more information.

Stateful interactions through hyperlinks: Every interaction with a resource is stateless; that is, request messages are self-contained. Stateful interactions are based on the concept of explicit state transfer. Several techniques exist to exchange state, such as URI rewriting, cookies, and hidden form fields. State can be embedded in response messages to point to valid future states of the interaction. See Using Entity Providers to Map HTTP Response and Request Entity Bodies and “Building URIs” in the JAX-RS Overview document for more information.

Java API for RESTful Web Services

JAX-RS: Java API for RESTful Web Services (JAX-RS) is a Java programming language API spec that provides support in creating web servicesaccording to the Representational State Transfer (REST) architectural pattern.[1] JAX-RS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints.

From version 1.1 on, JAX-RS is an official part of Java EE 6. A notable feature of being an official part of Java EE is that no configuration is necessary to start using JAX-RS. For non-Java EE 6 environments a small entry in the web.xml deployment descriptor is required.

The annotations in JAX-RS

The JAX-RS API forms an important part of the Java EE platform's commitment to providing standards-driven technology. The ubiquitous nature of the Internet and that recent increasing interest in the microservice architecture has put more focus on small, scalable, autonomous services and their interoperability. The principal methodology used to allow microservices to communicate with each other and the ‘outside world’ is REST and its use in developing RESTful APIs. The technology that Java EE provides for this is the JAX-RS: Java API for RESTful Web Services.

The goals of the JAX-RS API are:

POJO-based: To provide a collection of classes/interfaces and associated annotations to be used with POJOs so as to expose them as Web resources.

HTTP-centric: To use HTTP as the underlying network protocol and provide a clear mapping between HTTP and URI elements and the corresponding API classes and annotations.

Format independence: To be applicable to a wide variety of HTTP entity body content types and provide the necessary pluggability to allow additional types to be added.

Container independence: To ensure that artifacts using the API are deployable in a range of Web servers.

Inclusion in Java EE: To allow Java EE features and components to be used within a Web resource class.

JAX-RS Media Types