RESTful Web Services

Hey guys! welcome back to my Programming Applications and Frameworks article series. From today article I'm going to discuss some information about RESTful Webservices.





What is this Message oriented communication and resource-oriented communication?

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. 

We can classify message-oriented communication into 2 parts,
  1. synchronous asynchronous
  2. Transient or persistent
  • Synchronous communication - sender block until the request is known to be accepted.
  • Asynchronous com. - Sender continues immediately after the message sent.
  • Persistent com. - Stores the message until the recipient receives it.
  • Transient com. - Messages are stored as long as sending and receiving applications are executing.



Resource-oriented communication

RoCL, Resource oriented Communication, uses existing low-level communication libraries to interface networking hardware. As a new intermediate-level communication library it offers a novel approach to system programmers to facilitate the development of a higher-level programming environment that supports the resource-oriented computation paradigm of CoR. RoCL 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.

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 (corresponding to the standard HTTP GET, POST, PUT and DELETE methods), while an object instance typically has many methods.
Resources can be grouped into collections. Each collection is homogeneous so that it contains only one type of resource, and unordered. Resources can also exist outside any collection. In this case, we refer to these resources as singleton resources. Collections are themselves resources as well.

What is This "Representations" in REST style

A resource in REST is a similar Object in Object Oriented Programming or is like an Entity in a Database? Once a resource is identified then its representation is to be decided using a standard format so that the server can send the resource in the above-said format and the client can understand the same format. For example, in RESTful Web Services - First Application a user is a resource which is represented using the following XML format −

<user> 

   <id>1</id> 
   <name>Mahesh</name>
   <profession>Teacher</profession> 
</user>
The same resource can be represented in JSON format as follows-
{ 
   "id":1, 
   "name":"Mahesh", 
   "profession":"Teacher" 
}
Then what is a good resource representation? REST does not impose any restriction on the format of a resource representation. A client can ask for JSON representation whereas another client may ask for the XML representation of the same resource to the server and so on. It is the responsibility of the REST server to pass the client the resource in the format that the client understands. These are some important points to consider for representation formats,
  • Understandability
  • Completeness
  • Linkability

Let's get to know about the constraints of REST

There are 6 constraints that describe in REST architecture style,

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.

  • HTTP Verbs (GET,POST,PUT,DELETE)
  • URLs (resource name)
  • HTTP response (status nd body)
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 the 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.

RESTful service URLs

Under REST principles, a URL identifies a resource. The following URL design patterns are considered REST best practices,

  • URLs should include nouns, not verbs.
  • Use plural nouns only for consistency.
  • Use HTTP methods to operate on these resources.
  • Use HTTP response status code to represent the outcome of operations on resources.
Versioning
An API URL may contain a version number. If an API URL does not contain a version number, then it should be understood that always refers to the latest version. Anonymous API versions should not be considered stable, because the latest version changes with each release. Following is an example of an API URL that contains a version number.

GET /v1/path/to/resource HTTP/1.1
Host: www.example.gov.au
Accept: application/json, text/javascript

Formats
Allow users to request formats like JSON or XML.

URL Depth
The resource/identifier/resource URL pattern is sufficient for full attribute visibility between any resources. Therefore, this URL depth is usually sufficient to support any arbitrary resource graph. If your URL design goes deeper than resource/identifier/resource, it may be evidence that the granularity of your API is too coarse.

API Payload formats
To interact with an API, a consumer needs to be able to produce and consume messages in the appropriate format. For a successful interaction, both parties would need to be able to process (parse and generate) these messages.


Let's understand MVC for RESTful web service development

MVC is a paradigm from the Smalltalk world concerned with how object orientated systems could have UIs.
Early web frameworks took a general idea (separate out business logic, controlling logic and view logic) and applied the principle to how they structured the web application. Before this, it wasn't uncommon to have God awful mess of HTML generation code inside domain objects, or business logic inside HTML templates (think very early PHP)
The thing is that the original MVC from the Smalltalk world isn't really what MVC is in most web frameworks. An HTML output isn't really a "view" in the sense that Smalltalk understood a UI screen to be.
So that is the first reason not to get too hung up on whether you are following MVC properly. Hardly anything is. Take it less like a strict division and more a guideline of Hey wouldn't it be nice if our HTML templates weren't full of business logic.
Secondly, MVC is just a way of structuring server-side code. It really has nothing to do with REST/HTTP. REST is concerned with how clients and servers communicate. It doesn't care if the representation the server sends to the client is in an HTML template that took a lot to construct with a templating engine or a JSON object that was one call in the controller.
If you don't think your server needs a "view" layer that is fine. You will still gain benefit separating out your business logic (ie model) from the controllers that are handling a specific HTTP request, even if all the controller does it call a JSON parsing call on some object and return that data.


Advantages of MVC

  • Faster development process.
  • Ability to provide multiple views.
  • Support for asynchronous technique.
  • The modification does not affect the entire model.
  • MVC model returns the data without formatting.
  • SEO friendly development platform.

Disadvantages of MVC

  • Increased complexity.
  • The inefficiency of data access in view.
  • The difficulty of using MVC with a modern user interface.
  • Need multiple programmers.
  • Knowledge of multiple technologies is required.
  • The developer has knowledge of client-side code and HTML code.

What is this JAX-RS API?

The REST paradigm has been around for quite a few years now and it’s still getting a lot of attention.
A RESTful API can be implemented in Java in a number of ways: you can use Spring, JAX-RS, or you might just write your own bare servlets if you’re good and brave enough. All you need is the ability to expose HTTP methods – the rest is all about how you organize them and how you guide the client when making calls to your API.
As you can make out from the title, this article will cover JAX-RS. But what does “just an API” mean? It means that the focus here is on clarifying the confusion between JAX-RS and its implementations and on offering an example of what a proper JAX-RS web app looks like.

Annotations of JAX-RS

  • The @ApplicationPath Annotation
  • The @Path Annotation
  • The @GET HTTP Method Annotation
  • The @POST HTTP Method Annotation
  • The @PUT HTTP Method Annotation
  • The @DELETE HTTP Method Annotation
  • The @OPTIONS HTTP Method Annotation
  • The @HEAD HTTP Method Annotation
  • The @Path Annotation (again) and @PathParam
  • The @QueryParamter Annotation
  • The @Produces Annotation
  • The @Consumes Annotation
  • The @FormParam Annotation
  • The @MatrixParam Annotation
  • The @CookieParam Annotation
  • The @HeaderParam Annotation
  • The @Provider Annotation

Packages that use MediaType
PackageDescription
javax.ws.rs.client
The JAX-RS client API
javax.ws.rs.container
Container-specific JAX-RS API.
javax.ws.rs.core
Low-level interfaces and annotations used to create RESTful service resources.
javax.ws.rs.ext
APIs that provide extensions to the types supported by the JAX-RS API.
javax.ws.rs.sse
Server-Sent Events related API.



That's all about RESTful Web Services for this article and i think you got more knowledge about this area. See you guys with another article. Good luck!


references
  • https://studylib.net/doc/8093860/message--and-stream-oriented-communication
  • https://www.semanticscholar.org/paper/RoCL%3A-A-Resource-Oriented-Communication-Library-Alves-Pina/ea86fc900e736377a02c37a013b3af07babd3659
  • https://restful-api-design.readthedocs.io/en/latest/resources.html
  • https://www.tutorialspoint.com/restful/restful_resources.htm
  • https://apiguide.readthedocs.io/en/latest/build_and_publish/use_RESTful_urls.html
  • https://softwareengineering.stackexchange.com/questions/324730/mvc-and-restful-api-service
  • https://www.interserver.net/tips/kb/mvc-advantages-disadvantages-mvc/
  • https://dzone.com/articles/an-introduction-to-jax-rs-annotations-part-1
  • https://javaee.github.io/javaee-spec/javadocs/javax/ws/rs/core/class-use/MediaType.html



Comments

Post a Comment

Popular Posts