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. The sender blocks waiting for the receiver in synchronous communication.
Asynchronous communication does not require simultaneous execution of both the sender and the receiver. So the sender is loosely coupled with the recipient. Whether the communication is transient or persistent is determined by the amount of time messages stored. Transient communication only stores the message when both partners are executing the communication. 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.
A resource-oriented architecture (ROA) is the structural design supporting the internet working of resources. A resource, in this context, is any entity that can be identified and assigned a uniform resource identifier (URI).In information technology, architecture refers to the overall structure of an information system and the interrelationships of entities that make up that system. ROA is considered a RESTful architecture. REST (representational state transfer) is defined by Roy Fielding, co-author of the HTTP specification and co-founder of the Apache HTTP server project, as an architectural style that exploits the existing technology and protocols of the Web, including HTTP and XML.
Four essential concepts
Resources
Their names (URIs)
Their representations
The links between them
Four properties:
Address-ability
Statelessness
Connectedness
A uniform interface
The idea behind REST is that applications, i.e., clients, interact with APIs by retrieving and manipulating exposed representations of resources. A resource can be a real world object or a data object on the web. The representation of a resource details the current state of the resource. The characteristic of a dynamic data source is a very high update rate of the resource states. To enable clients to capture the resulting velocity of the data, dynamic data sources often expose a stream of data, which provides the information about the occurring state updates.
REST architecture treats as a resource every content. These resources may be text files, html pages, images, videos or business data dynamics. REST Server provides resource access and REST client access and resource modification. URIs / Global IDs identify each resource here. REST uses different representations to represent a resource that includes Text, JSON, XML.
A resource in REST is or is like an entity in a database, a similar object in object - oriented programming. Once a resource is identified, its representation must be decided using a standard format to enable the server to send the resource in the format mentioned above and the client can understand the same format.
Following are some important points to be considered while designing a representation format of a resource in RESTful Web Services.
Understand-ability - Both the Server and the Client should be able to understand and utilize the representation format of the resource.
Completeness - Format should be able to represent a resource completely. For example, a resource can contain another resource. Format should be able to represent simple as well as complex structures of resources.
Linkablity - A resource can have a linkage to another resource, a format should be able to handle such situations.
most of the web services are representing resources using either XML or JSON format. There are plenty of libraries and tools available to understand, parse, and modify XML and JSON data.
REST Constraints
REST constraints are design rules that are applied to establish the distinct characteristics of the REST architectural style. If you follow all constraints designed by the REST architectural style your systems is considered RESTful.
These constraints don't dictate what kind of technology to use; they only define how data is transferred between components and what benefits we get following the guidelines. Therefore, a RESTful system can be implemented in any networking architecture available.
- Client-Server
- Stateless
- Cache able
- Uniform Interface
- Layered System
- Code On Demand (Optional)
The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. REST distinguishes three classes of architectural elements, they are:
- Connectors
Components
- Data Elements
Connectors
Connectors represent the activities involved in accessing resources and transferring representations. Roles provide an interface for components to implement. REST encapsulates different activities of accessing and transferring representations into different connector types.
Components
In REST, the various software that interacts with one another are called components
Data Elements
The 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 identifies six data elements: a resource, resource identifier, resource metadata, representation, representation metadata, and control data.
RESTful API
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 technology for representational state transfer (REST), architectural style, and communication approaches that are often used in the development of web services.
REST technology is generally preferred to the more robust Simple Object Access Protocol (SOAP) technology because REST leverages less bandwidth, making it more suitable for internet usage. An API for a website is code that allows two software programs to communicate with each another . The API spells out the proper way for a developer to write a program requesting services from an operating system or other application.
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 flexibility, 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 Open Stack Swift are the most popular.
Pros
- Strong URL Routing support to create clean URLs using familiar MVC - style semantics routing Support for a variety of output formats supported including JSON, XML, ATOM
- Strong standard REST semantics support but optional
- Easily extended support for For matter to add new types of input / output
- Very extensible, based on MVC, like For matters and Filters extensibility model
- Self host able in non-Web applications
- Deep support for more advanced HTTP features through HAPT Response Message and HAPT Request Message classes and Enums strongly typed to describe many HTTP operations
- Testable using testing concepts similar to MVC
cons
1.Web API is MVC - like, but not the same
2.Code Duplication
3.Conclusion
The JAX-RS API and its implementations
*JAX - RS stands for RESTful Web Services JAVA API. JAX - RS is a JAVA programming language API and specification to support the RESTful Web Services that have been created.
*Its 2.0 release was released on May 24, 2013. JAX - RS uses Java SE 5 annotations to simplify the development and deployment of JAVA - based web services.
*It also supports the creation of RESTful Web Services customers.
*There are two main implementation of JAX-RS API
1.Jersey
2.RESTEasy
JAX-RS
*The JAX - RS API uses annotations to supply meta - data around the web resource.
1.The @Path Annotation (again) and @PathParam
*The @Path annotation can be used to further refine the location of a resource using the resource method.
*import javax.ws.rs.Path
2.The @QueryParamter Annotation
*A query parameter is the value associated with the key/value pair appended to a URL after the ? symbol.
*import javax.ws.rs.QueryParam
3.The @Produces Annotation
*The @Produces annotations specify the type of media or types returned to the caller by the method.
**import javax.ws.rs.Produces
4.The @Consumes Annotation
*You can specify the media type that a method can consume with the @Consumes annotation.
5.@DELETE
*@DELETE annotation corresponds to HTTP DELETE method.
6.@GET, @POST
*To map the HTTP methods to methods in the resource representing class. For example, @GET can be placed on getBook method.
“Media type” in JAX-RS
All methods of resource can consume and produce content of almost any kind. If you submit a POST request to a URI, such as api/books, the REST API expects that the HTTP body will have a payload that is the resource it should create
*This resource can be represented using any media type.
0 comments:
Post a Comment