RESTful Web Services

                                                            RESTful Web services

Compare and contrast Message oriented communication with resource oriented communication

Message Oriented Communication	Resource Oriented Communication
Persistence and synchronicity	Data stream
Message-oriented transient communication • Berkeley socket • MPI	Quality of services
Message-oriented persistent communication	Stream synchronization

Discuss the resource based nature of the REST style

·         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.

Explain the meaning of “representations” in REST style

Resource Data :

Resources have data associated with them. The richness of data that can be associated with a resource is part of the resource model for an API. It denes for example the available data types and their behavior.

Based on my experience, I have developed a strong conviction that the JSON data model has just the right “richness” so that it is an ideal data model for RESTful resources. I would recommend that everybody use it.

In JSON, just three types of data exist:

scalar (number, string, boolean, null). array object Scalar types have just a single value. Arrays contain an ordered list of values of arbitrary type. Objects consist of a unordered set of key:value pairs (also called attributes, not to be confused with XML attributes), where the key is a string and the value can have an arbitrary type. For more detailed information on JSON, see the JSON web site.

In REST style representations mean we can get,

·        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, files, etc..

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

Constraint,

01.   Client-server

02.   Layered system

03.   Stateless

04.   Cacheable

05.   Code-on-demand

06.   Uniform interface

Client:

server This essentially means that client application and server application MUST be able to evolve separately without any dependency on each other. A client should know only resource URIs and that’s all. Today, this is normal practice in web development so nothing fancy is required from your side. Keep it simple.

Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.

Layered system :

REST allows you to use a layered system architecture where you deploy the APIs on server A, and store data on server B and authenticate requests in Server C, for example. A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way.

Stateless :

Roy elding got inspiration from HTTP, so it reects in this constraint. Make all client-server interaction stateless. Server will not store anything about latest HTTP request client made. It will treat each and every request as new. No session, no history.If client application needs to be a stateful application for the end user, where user logs in once and do other authorized operations thereafter, then each request from the client should contain all the information necessary to service the request – including authentication and authorization details.No client context shall be stored on the server between requests. The client is responsible for managing the state of the application.

Cacheable:

 In today’s world, caching of data and responses is of utmost important wherever they are applicable/possible. The webpage you are reading here is also a cached version of the HTML page. Caching brings performance improvement for client side, and better scope for scalability for a server because the load has reduced.

Code on demand:

 (optional) Well, this constraint is optional. Most of the time you will be sending the static representations of resources in form of XML or JSON. But when you need to, you are free to return executable code to support a part of your application e.g. clients may call your API to get a UI widget rendering code. It is permitted.

Uniform interface:

 As the constraint name itself applies, you MUST decide APIs interface for resources inside the system which are exposed to API consumers and follow religiously. A resource in the system should have only one logical URI and that should provide a way to fetch related or additional data. It’s always better to synonymise a resource with a web page.

All above constraints help you build a truly RESTful API and you should follow them. Still, at times you may nd yourself violating one or two constraints. Do not worry, you are still making a RESTful API – but not “truly RESTful”.

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

Component	Examples
User agent	Browser-based-application
Origin server	Server-side application
proxy	CERN Proxy, Netscape Proxy, Gauntlet
gateway	Squid, CGI, Reverse Proxy

Explain how to define the API of Restful web services using Restful URLs

A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT , POST and DELETE data.

A RESTful API -- also referred to as a RESTful web service -- is based on representational state transfer (REST) technology, an architectural style and approach to communications often used in web services development.

How RESTful APIs work

 A RESTful API breaks down a transaction to create a series of small modules. Each module addresses a particular underlying part of the transaction. This modularity provides developers with a lot of exibility, but it can be challenging for developers to design from scratch. Currently, the models provided by Amazon Simple Storage Service, Cloud Data Management Interface and OpenStack Swift are the most popular.

 A RESTful API explicitly takes advantage of HTTP methodologies dened by the RFC 2616 protocol. They use GET to retrieve a resource; PUT to change the state of or update a resource, which can be an object, le or block; POST to create that resource ; and DELETE to remove it.

 With REST, networked components are a resource you request access to -- a black box whose implementation details are unclear. The presumption is that all calls are stateless; nothing can be retained by the RESTful service between executions.

Because the calls are stateless, REST is useful in cloud applications. Stateless components can be freely redeployed if something fails, and they can scale to accommodate load changes. This is because any request can be directed to any instance of a component; there can be nothing saved that has to be remembered by the next transaction. That makes REST preferred for web use, but the RESTful model is also helpful in cloud services because binding to a service through an API is a matter of controlling how the URL is decoded. Cloud computing and microservices are almost certain to make RESTful API design the rule in the future.

The model-view-controller (MVC) has been the traditional architectural pattern for developing applications having user interface, which later on evolved to MVP and MVVM architectures, as Martin Fowler explains.

dentify the annotations in JAX-RS, explaining their use

Annotation	Description
@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 method. The Java method annotated with this request method designator will process HTTP DELETE requests. The behavior of a resource is determined by the HTTP method to which the resource is responding.

Explain the use and importance of “media type” in JAX-RS

1- View depends both on Controller and Model

 This means there is not a single source of updating the View. In fact, if updating the UI requires data (e.g. from network or database), the View gets it from the Model. If not (e.g. hiding or showing the progress bar or going to another activity), the View gets the updates from the Controller.

 Therefore, for unit testing the View, both Controller and Model must be mocked.

 2- Model is doing too much work

 It does too many things from getting the data from the network/database to informing the Controller about whether it could get the data or not, and even preparing the result to be displayed on the View.

 3- Who controls the UI logic?

 Should the View show the data it gets from the Model directly to the user?

 if true, then the Model is handling the UI logic, which is intuitively not appropriate. Otherwise, View handling the UI logic is not good as well, since the View should only know how display the UI rather than judging on the content it displays.

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

All resource methods can consume and produce content of almost any type. If you make a POST request to a URI, such as api/books, the REST API expects the HTTP body to contain a payload that represents the resource it should create.

This resource can be represented using any media type. Although typically, it will be represented in either, JSON or XML, but it could be plain text, binary or a custom format. It doesn’t matter, as long as there is a method in the resource class that can consume that media type.