·
Messages are sent through a channel abstraction
·
The channel connects two running processes
·
Time coupling between sender and receiver
·
Transmission time is measured in terms of
milliseconds, typically
Resource Oriented Communication
·
Main focus is about Request addressing.
·
Unique address per resource.
·
Application interface is generic to the
request mechanism.
·
Nothing directly linked to address/ URL.
What Are RESTful
Web Services?
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 Bodiesand
“Building URIs” in the JAX-RS Overview document for more information.
REST
is Resource-based, Focuses on Representations
(of data/information/resources) and 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.
Focuses
on 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…
Derived
using Six Constraints
Fielding
created these constraints with the ultimate goal of making applications faster,
more reliable, and easier to scale. As a web service designer, your service
should try to comply with these constraints as closely as possible in order to
reap their benefits. So, let’s dive into them.
Client-server - The REST is for
explicitly for networked distributed systems, which are based on the
client-server style
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.
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.
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.
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.
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.
Identification of resources
- Based on the web’s Request-Response model
manipulation of resources through
representations - Response = HTML, XML, JSON, TXT, SVG, PNG…
Self-descriptive representation
-
{
"name": “John",
"job": “Web
Developer",
"hobbies": ["blogging",
"coding", "music"]
}
Hypermedia as the engine of application state Request
= URL + HTTP Verbs (GET, POST, PUT, DELETE)
Ex - HTTP/1.1 GET http://abc.com/user/John
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
|
component
|
examples
|
|
User agent
|
Browser-based-application
|
|
Origin server
|
Server-side application
|
|
proxy
|
CERNProxy, NetscapeProxy, Gauntlet
|
|
gateway
|
Squid,CGI,ReverseProxy
|
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.
|
Connector
|
examples
|
|
Client
|
Browser
|
|
Server
|
Web Server
|
|
Cache
|
Browser cache, Akamai cache network
|
|
Resolver
|
DNS lookup, DOI lookup
|
|
tunnel
|
SOCKS, SSL after HTTP CONNECT
|
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
|
Data
|
examples
|
|
Resource
|
Conceptual target of a hypertext reference
|
|
Resource identifier
|
URL, URN
|
|
Representation
|
HTML document, JPEG image, XML dataset
|
|
Representation metadata
|
Media type, last-modified time
|
|
Resource metadata
|
Source link, alternates
|
|
Control data
|
If-modified-since, cache-control
|
RESTFul
URL
Request
= URL + HTTP Verbs (GET,POST,PUT,DELETE)
|
Request
|
Collection/ Single/ Multiple
|
URL
|
|
GET
|
Collection
|
|
|
|
Single item
|
|
|
|
Multiple
|
|
|
POST
|
Single
|
|
|
PUT
|
Collection
|
|
|
|
Single item
|
|
|
|
Multiple
|
|
|
DELET
|
Collection
|
|
|
|
Single item
|
|
|
|
Multiple
|
MVC
- Model-View-Controller
s an architectural pattern that separates an application into
three main logical components: the model, the view, and the controller. Each of these components are
built to handle specific development aspects of an application. MVC is one of
the most frequently used industry-standard web development frameworks to create
scalable and extensible projects.
Model
The Model
component corresponds to all the data-related logic that the user works with.
This can represent either the data that is being transferred between the View
and Controller components or any other business logic-related data. For
example, a Customer object will retrieve the customer information from the
database, manipulate it and update it data back to the database or use it to
render data.
View
The View
component is used for all the UI logic of the application. For example, the
Customer view will include all the UI components such as text boxes, dropdowns,
etc. that the final user interacts with.
Controller
Controllers act
as an interface between Model and View components to process all the business
logic and incoming requests, manipulate data using the Model component and
interact with the Views to render the final output. For example, the Customer
controller will handle all the interactions and inputs from the Customer View
and update the database using the Customer Model. The same controller will be
used to view the Customer data.
JAX-RS is a Java
programming language API designed to make it easy to develop applications that
use the REST architecture.
The JAX-RS API
uses Java programming language annotations to simplify the development of
RESTful web services. Developers decorate Java programming language class files
with JAX-RS annotations to define resources and the actions that can be
performed on those resources. JAX-RS annotations are runtime annotations;
therefore, runtime reflection will generate the helper classes and artifacts
for the resource. A Java EE application archive containing JAX-RS resource
classes will have the resources configured, the helper classes and artifacts
generated, and the resource exposed to clients by deploying the archive to a
Java EE server.
|
Annotation
|
Description
|
|
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}.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
The @HEAD 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 HEAD
requests. The behavior of a resource is determined by the HTTP method to
which the resource is responding.
|
|
|
The @PathParam annotation is a type of
parameter that you can extract for use in your resource class. URI path
parameters are extracted from the request URI, and the parameter names
correspond to the URI path template variable names specified in the @Path class-level
annotation.
|
|
|
The @QueryParam annotation is a type of
parameter that you can extract for use in your resource class. Query
parameters are extracted from the request URI query parameters.
|
|
|
The @Consumes annotation is used to specify
the MIME media types of representations a resource can consume that were sent
by the client.
|
|
|
The @Produces annotation is used to specify
the MIME media types of representations a resource can produce and send back
to the client: for example, "text/plain".
|
|
|
The @Provider annotation is used for anything
that is of interest to the JAX-RS runtime, such as MessageBodyReader andMessageBodyWriter.
For HTTP requests, the MessageBodyReader is used to map an HTTP
request entity body to method parameters. On the response side, a return
value is mapped to an HTTP response entity body by using a MessageBodyWriter.
If the application needs to supply additional metadata, such as HTTP headers
or a different status code, a method can return aResponse that wraps the
entity and that can be built using Response.ResponseBuilder.
|
https://www.tutorialspoint.com/mvc_framework/mvc_framework_introduction.htm
No comments:
Post a Comment