RESTful Web
services
Message-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
communication
Resource oriented communication is a
communication library that aims to exploit the low-level communication
facilities of today’s cluster networking hardware and to merge, via the
resource oriented paradigm, those facilities and the high-level degree of
parallelism achieved on SMP systems through multi-threading. The communication
model defines three major entities – contexts, resources and buffers – which
permit the design of high-level solutions. A low-level distributed directory is
used to support resource registering and
discovering. The usefulness and applicability of RoCL is briefly addressed
through a basic modelling example – the implementation of TPVM over RoCL.
Performance results for Myrinet and Gigabit Ethernet, currently supported in
RoCL through GM and MVIA, respectively, are also presented. Keywords: cluster
computing, message-passing, directory, multi-threading.
Resource based nature of
the REST style
•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
“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…
•E.g. the state of a student (as per
the database) can be represented by a resource of webpage, XML dataset, etc…
Constraints of REST
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 clientstate.
•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
Uniform Interface –Identification of resources •Based
on the web’s Request-Response model
•Request = URL + HTTP Verbs
(GET,POST,PUT,DELETE) •HTTP/1.1 GET http://abc.com/user/John
•Response = HTML, XML, JSON, TXT,
etc…
{
"name": “John",
"job": “Web
Developer",
"hobbies": ["blogging",
"coding", "music"]
}
Implementations for the
elements of REST style
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
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
•connectors are abstract interfaces
for component communication, enhancing simplicity by hiding the underlying
implementation of resources and communication mechanisms
RESTful web services using
RESTful URLs
Request = URL + HTTP Verbs
(GET,POST,PUT,DELETE)
•URL is the key technique in RESTful
communication
•The API of the RESTful service is a
set of URLs
•The resource is determined by the
URL segments
•The CRUD operations are determined
by the HTTP verb
Operation=Read, Verb=GET
•Collection
•SLIIT.com/students/
•SLIIT.com/students/DS
•SLIIT.com/students/DS/IT123456/posts
•Single
item
•SLIIT.com/students/IT123456
•Blog.com/posts/pid15948
•Multiple
items
•SLIIT.com/students/IT123456;IT456456;IT998877
Operation=Create, Verb=POST
•Single item
(single item in the payload)
•SLIIT.com/students/
•SLIIT.com/students/DS
•SLIIT.com/students/DS/IT123456/posts
•Multiple items
•Same URL, items will be in the
payload
Operation=Update, Verb=PUT
•Collection (data in the payload)
•SLIIT.com/students/
•SLIIT.com/students/DS
•SLIIT.com/students/DS/IT123456/posts
•Single item
•SLIIT.com/students/IT123456
•Blog.com/posts/pid15948
•Multiple items
•SLIIT.com/students/IT123456;IT456456;IT998877
Operation=Delete, Verb=DELETE
•Collection
•SLIIT.com/students/
•SLIIT.com/students/DS
•SLIIT.com/students/DS/IT123456/posts
•Single item
•SLIIT.com/students/IT123456
•Blog.com/posts/pid15948
•Multiple items
•SLIIT.com/students/IT123456;IT456456;IT998877
MVC for RESTful web service
development
JAX-RS API
•JAX-RS is an API
•There are two implementations
1.
jersey
2.RESTeasy
Annotations in JAX-RS
Annotation
@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
Importance of “media type”
in JAX-RS
Hello.java
packagecom.javatpoint.rest; importjavax.ws.rs.*;
importjavax.ws.rs.core.MediaType;
@Path("/hello")
publicclassHello{ @GET @Produces(MediaType.TEXT_PLAIN) publicStringsayPlainTextHello(){
return"Helloworld";
}
}
Web.xml <servlet-mapping>
<servlet-name>JerseyRESTService</servlet-name>
<url-pattern>/rest/*</url-pattern> </servlet-mapping>
index.html
<ahref="rest/hello">ClickHere</a>
