Breif discusion on Server-side Development-Part02


Hello friends welcome back to my blog. This is 2nd part of the server side development. If you don't read my previous blog you can click here. In this blog I'm going to talk about Resource oriented communication; REST.

First let's find the difference between Message oriented communication and resource oriented communication.

Message oriented communication VS Resource oriented communication



REST-Representational State Transfer


  • REST is an architectural structure style for the service of web.
  • WWW including servers, proxies, switches, routers etc were improved based on REST.
  • REST is use not only for the the services, also used for distributed systems and it cover everything. 
  •  REST is resource-based. 
  • It is focus on Things(based on nouns ) more than Actions(based on verbs).
  • There can be actions related to items. But its main focus on things.
  • There for REST focus on Resources. These resources are identified by URIs. 
  • REST is focuses on Representations. 
  • REST is Derived using Six Constraints .
    1. Client-server
    2. Layered system
    3. Stateless
    4. Cacheable
    5. Code-On-Demand
    6. Uniform Interface 

Representations in REST 


 I want to think about representations. Suppose a client makes a GET request to /programmers/Namespacinator and gets back this JSON response:

{
    "nickname": "Namespacinator",
    "powerLevel": 5
} 
 
That’s the programmer resource, right? Wrong! No!
This is just a representation of the programmer resource. It happens to be in JSON, but the server could have represented the programmer in other ways, like in XML, HTML or even in JSON with a different format.
The same applies when a client sends a request that contains programmer data:

POST /api/programmers HTTP/1.1
Host: CodeBattles.io
Authorization: Bearer b2gG66D1Tx6d89f3bM6oacHLPSz55j19DEC83x3GkY
Content-Type: application/json

{
    "nickname": "Namespacinator"
}
 
The client doesn’t send a programmer resource, it just sends a representation. The server’s job is to interpret this representation and update the resource.

Representation State

This is exactly how browsing the web works. An HTML page is not a resource, it’s just one representation. And when we submit a form, we’re just sending a different representation back to the server
One resource could have many representations. Heck, you could get crazy and have an API where you’re able to request the XML, JSON or HTML representations of any resource. We’re just crazy enough that we’ll do some of that.
A representation is a machine readable explanation of the current state of a resource.
Yes, I said the current “state” of the resource, and that’s another important and confusing term. What REST calls state, you probably think of as simply the “data” of a resource. When the client makes a GET request to /programmer/Namespacinator, the JSON is a representation of its current state, or current data. And if the client makes a request to update that programmer, the client is said to be sending a representation in order to update the “state” of the resource.
In REST-speak, a client and server exchange representations of a resource, which reflect its current state or its desired state. REST, or Representational state transfer, is a way for two machines to transfer the state of a resource via representations.

Constraints of REST


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.
Any single resource should not be too large and contain each and everything in its representation. Whenever relevant, a resource should contain links (HATEOAS) pointing to relative URIs to fetch related information.
Also, the resource representations across system should follow certain guidelines such as naming conventions, link formats or data format (xml or/and json).
All resources should be accessible through a common approach such as HTTP GET and similarly modified using a consistent approach.
Once a developer becomes familiar with one of your API, he should be able to follow the similar approach for other APIs.

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.

Stateless

Roy fielding got inspiration from HTTP, so it reflects 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.
In REST, caching shall be applied to resources when applicable and then these resources MUST declare themselves cacheable. Caching can be implemented on the server or client side.
Well-managed caching partially or completely eliminates some client-server interactions, further improving scalability and performance.

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.

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.




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
           •connectors are abstract interfaces for component
            communication, enhancing simplicity by hiding
            the underlying implementation of resources and
            communication mechanisms


  • 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

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

JAX-RS


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 webapp looks like.

JAX-RS is nothing more than a specification, a set of interfaces and annotations offered by Java EE. And then, of course, we have the implementations; some of the more well known are RESTEasy and Jercy.
Also, if you ever decide to build a JEE-compliant application server, the guys from Oracle will tell you that, among many other things, your server should provide a JAX-RS implementation for the deployed apps to use. That’s why it’s called Java Enterprise Edition Platform.
Another good example of specification and implementation is JPA and Hibernate.

Annotations of JAX-RS




REFERENCE

https://symfonycasts.com/screencast/rest/rest
https://restfulapi.net/rest-architectural-constraints/
https://docs.oracle.com/javaee/6/tutorial/doc/gilik.html
https://www.baeldung.com/jax-rs-spec-and-implementations

Comments

Post a Comment

Popular posts from this blog

How to run multiple Transformations from one Job in Pentaho

Image
In this article I am going to talk about how to run multiple transformations from one job using Pentaho. I hope you'll know about pentaho, transformations and jobs. This article include two ways of doing the same process. one method is simple, easy but not much efficient way. However, the second method is more efficient and success way. First,let's talk about the easy method, This is the the most common method that you can find from the internet. And also, this is very easy method that fulfill the requirement of running multiple transformations from one job.  Let me share an example of this approach and discuss how we are going create this job and the drawbacks of this method. Fig 01: Easy method for run multiple transformations at once As you can see in above image, There are 4 transformations connected with the start and when run the   above job all of the execute and run sequentially. If you need to run all of the together in parallel, you can change the settings ...
Read more

Data Analytics

Image
                        What is Data Analytics? As the process of analyzing raw data to find trends and answer questions, the definition of data analytics captures its broad scope of the field. However, it includes many techniques with many different goals. The data analytics process has some key components that are needed for any initiative. By combining these components, a successful data analytics initiative will provide a clear picture of where you are, where you have been and where you should go. Generally, this process begins with  descriptive analytics . This is the process of describing historical trends in data. Descriptive analytics aims to answer the question “what happened?” This often involves measuring traditional indicators such as return on investment (ROI). The indicators used will be different for each industry. Descriptive analytics does not make predictions or directly inform decisions. It...
Read more

Distributed Systems

Image
Difference between distributed systems and distributed computing Distributed systems and distributed computing are looks like same. But they slightly different from each other. So let’s talk about them. In Distributed- computing there are multiple computing units connected to achieve a common task. When considering a single unit, larger computing power enables lot of tasks to be perform. And also searches can be coordinated for efficiency, Successes usually give the finder credit. Distributed computing projects include hunting large prime number, and analysing DNA codes. A Distributed system includes a collection of autonomous computers, connected through a network and distribution middleware, which enables computers to coordinate their activities and to share the resources of the system, so that users perceive the system as a single, integrated computing facility. So hope you can now understand the differences. Standalone system VS Distributed system ...
Read more