Restfull Services

Compare and contrast Message oriented communication with resource oriented communication

Message-oriented communication is a way of communicating between processes. Messages, which correspond to events, are the basic units of data delivered. Tanenbaum and Steen classified message-oriented communication according to two factors---synchronous or asynchronous communication, and transient or persistent communication. In synchronous communication, the sender blocks waiting for the receiver to engage in the exchange. Asynchronous communication does not require both the sender and the receiver to execute simultaneously. So, the sender and recipient are loosely-coupled. The amount of time messages are stored determines whether the communication is transient or persistent. Transient communication stores the message only while both partners in the communication are executing. If the next router or receiver is not available, then the message is discarded. Persistent communication, on the other hand, stores the message until the recipient receives it.

Resource Oriented Architectures (ROA) are based upon the concept of resource; each

resource is a directly accessible distributed component that is handled through a standard,

common interface making possible resources handling. RESTFul platforms based on

REST development technology enable the creation of ROA.

The main ROA concepts are the following 

• Resource

– anything that’s important enough to be referenced as a thing itself

• Resource name

– unique identification of the resource

• Resource representation

– useful information about the current state of a resource

• Resource link

– link to another representation of the same or another resource

• Resource interface

– uniform interface for accessing the resource and manipulating its state

Discuss the resource based nature of the REST style

The fundamental concept in any RESTful API is the resource. A resource is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. It is similar to an object instance in an object-oriented programming language, with the important difference that only a few standard methods are defined for the resource, while an object instance typically has many methods.

Explain the meaning of “representations” in REST style

•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…

For Example-

Resource– Author (Dinesh)

Service– Contact information about dinesh (GET)

Representation-name,mobile, address as JSON or XML format

Discuss the constraints of REST, indicating their use in the domain of web

REST architecture style describe six constraints for REST APIs.

1. Uniform Interface

The uniform interface constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently.

For us this means

HTTP Verbs (GET,POST,PUT,DELETE)

URIs (resource name)

HTTP response (status and body)

The four guiding principles of the uniform interface are:

1.1) Identifying the resource – Each resource must have a specific and cohesive URI to be made available.

1.2) Resource representation – Is how the resource will return to the client. This representation can be in HTML, XML, JSON, TXT, and more. 

1.3) Self-descriptive Messages – Each message includes enough information to describe how to process the message. Beyond what we have seen so far, the passage of meta information is needed (metadata) in the request and response. Some of this information are: HTTP response code, Host, Content-Type etc. 

1.4) Hypermedia as the Engine of Application State (HATEOAS)– Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. This part is often overlooked when talking about REST. It returns all the necessary information in response so client knows how to navigate and have access to all application resources.

2. Stateless

One client can send multiple requests to the server; however, each of them must be independent, that is, every request must contain all the necessary information so that the server can understand it and process it accordingly. In this case, the server must not hold any information about the client state. Any information status must stay on client – such as sessions.

3. Cacheable

Because many clients access the same server, and often requesting the same resources, it is necessary that these responses might be cached, avoiding unnecessary processing and significantly increasing performance.

4. Client-Server

The uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.

5. Layered System

A client cannot ordinarily tell 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.

6. Code-On-Demand (Optional)

This condition 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. Thus, different customers may behave in specific ways even using exactly the same services provided by the server. As this item is not part of the architecture itself, it is considered optional. It can be used when performing some of the client-side service which is more efficient or faster.

Identify contemporary examples of different types of implementations for the elements of REST style 

REST distinguishes three classes of architectural elements, they are:

Connectors

Components

Data Elements

Components

•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

Connector

•represent activities involved in accessing resources and transferring representations.

•REST encapsulates different activities of accessing and transferring representations into different connector types

•connectors are abstract interfaces for component communication, enhancing simplicity by hiding the underlying implementation of resources and communication mechanisms

Data

• key aspect of REST is the state of the data elements, its components communicate by transferring representations of the current or desired state of data elements

•REST manages data in the following ways:

• render the data(traditional client-server style) where it is located and send a fixed-format image to the recipient,

• encapsulate the data(mobile object style) with a rendering engine and send both to the recipient or,

• send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine

Explain how to define the API of 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.

Discuss the JAX-RS API and its implementations

Developing RESTful Web services that seamlessly support exposing your data in a variety of representation media types and abstract away the low-level details of the client-server communication is not an easy task without a good toolkit. In order to simplify development of RESTful Web services and their clients in Java, a standard and portable JAX-RS API has been designed. Jersey RESTful Web Services framework is open source, production quality, framework for developing RESTful Web Services in Java that provides support for JAX-RS APIs and serves as a JAX-RS Reference Implementation.

Jersey framework is more than the JAX-RS Reference Implementation. Jersey provides it’s own API that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development. Jersey also exposes numerous extension SPIs so that developers may extend Jersey to best suit their needs.

Identify the annotations in JAX-RS, explaining their use 

Annotations in the JAX-RS API are used to provide meta-data around the web resource. A typical example is to use the @GET annotation with the @Path annotation to identify the method that should handle a GET request to the specified URI in the @Path annotation.

What follows is a very quick overview of the annotations available to mark the methods and classes used to construct web resources. This is not an exhaustive list, there are a few more annotations in the JAR-RS arsenal, however, as the majority of the work of JAX-RS is in configuration and handling web resources, this is where you will find the majority of the API's annotations put to use.

@Path The @Path annotation’s value is a relative URI path indicating where the Java class will be hosted: for

example, /helloworld. You can also embed variables in the URIs to make a URI path template. For example,

you could ask for the name of a user and pass it to the application as a variable in the

URI:/helloworld/{username}.

@GET The @GET annotation is a request method designator and corresponds to the similarly named HTTP

method. The Java method annotated with this request method designator will process HTTP GET requests.

The behavior of a resource is determined by the HTTP method to which the resource is responding.

@POST The @POST annotation is a request method designator and corresponds to the similarly named HTTP

method. The Java method annotated with this request method designator will process HTTP POST requests.

The behavior of a resource is determined by the HTTP method to which the resource is responding.

@PUT The @PUT annotation is a request method designator and corresponds to the similarly named HTTP

method. The Java method annotated with this request method designator will process HTTP PUT requests.

The behavior of a resource is determined by the HTTP method to which the resource is responding.

@DELETE The @DELETE annotation is a request method designator and corresponds to the similarly named HTTP