Study About REST Services & KoaJS
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.
Data and functionality are considered resources in the REST architectural style, and they are accessed through Uniform Resource Identifiers (URIs), which are usually links on the Web. A series of simple, well-defined operations are used to operate on the resources. The REST architectural style constrains an architecture to a client/server model and is designed to use a stateless communication protocol, most commonly HTTP. Clients and servers exchange representations of resources using a standardized interface and protocol in the REST architecture style.
The following principles encourage RESTful applications to be simple, lightweight, and fast:
- Resource identification through URI
- Uniform interface
- Self-descriptive messages
- Stateful interactions through hyperlinks
REST architectural Model
- REST-REpresentational State Transfer
- Six Constraints
The REST architectural style describes six constraints. These constraints, applied to the architecture, were originally communicated by Roy Fielding in his doctoral dissertation and defines the basis of RESTful-style.
REST is resource based API because RESTful API is as below points
- Things vs Actions
- Nouns vs Verbs
- Identified by URIs
- Multiple URIs may refer to the same resource as like CRUD operation on student resource using HTTP verbs.
- Separate from their representations-resource may represent as per as request content type either JSON or XML etc.
- How resources get manipulated
- Part of the resource state-transferred between client and server
- Typically JSON or XML
Resource– Author (Rozanne)
Service– Contact information about Rozanne (GET)
Representation- Name, mobile, address as JSON or XML format
REST architecture style describes six constraints for REST APIs.
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, such as;
- HTTP Verbs (GET,POST,PUT,DELETE)
- URIs (resource name)
- HTTP response (status and body)
The four guiding principles of the uniform interface are:
1.1) Identifying the resource — Each resource must have a specific and cohesive URI to be made available
1.2) Resource representation — Is how the resource will return to the client. This representation can be in HTML, XML, JSON, TXT, and more.
1.3) Self-descriptive Messages — Each message includes enough information to describe how to process the message. Beyond what we have seen so far, the passage of meta information is needed (metadata) in the request and response. Some of this information are HTTP response code, Host, Content-Type etc.
1.4) Hypermedia as the Engine of Application State (HATEOAS)– Clients deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services deliver the state to clients via body content, response codes, and response headers. This part is often overlooked when talking about REST. It returns all the necessary information in response to the client knows how to navigate and have access to all application resources.
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.
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.
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.
5. Layered System
A client cannot ordinarily tell 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.
6. Code-On-Demand (Optional)
This condition 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. Thus, different customers may behave in specific ways even using exactly the same services provided by the server. As this item is not part of the architecture itself, it is considered optional. It can be used when performing some of the client-side services which are more efficient or faster.
Compliance with REST constraints
● Simplicity — Uniform interface
● Modifiability — Change components while running
● Visibility — Communication between agents
● Portability — Components, by moving program code with data
What Is KoaJS?
Koa is a new web framework designed by the team behind Express, which aims to be a smaller, more expressive, and more robust foundation for web applications and APIs. By leveraging async functions, Koa allows you to ditch callbacks and greatly increase error-handling. Koa does not bundle any middleware within its core, and it provides an elegant suite of methods that make writing servers fast and enjoyable.
Who uses Koa.js?
Many companies use Koa.js framework for their websites and web APIs. Below is a shortlist of five globally recognized companies that use Koa.js framework.
Features that Differentiate Koa.js from Other Node.js Frameworks
1. Small Footprint
Koa.js is designed as a lightweight and flexible framework for Node.js. Hence, it has a smaller footprint than other Node.js frameworks. While developing server side apps, many developers use Koa.js to write thinner and better middleware. However, they still have option to extend the framework according varying project requirements by plugging in a wide range of modules.
2. Modern and Futuristic
Unlike conventional Node.js frameworks, Koa.js is built based on ECMAScript 6 or ECMAScript 2015 specification. ECMAScript 2015 simplifies development of complex application by providing a number of new classes and modules. Koa.js also uses generators which are a part of ECMAScript 2015 specification. Hence, it helps developers to create applications that remain relevant over a longer period of time.
As noted earlier, Koa.js uses an ECMAScript 2015 specification — generators. In addition to simplifying synchronous programming, generators further facilitate both upstream and downstream flow of controls. The developers can even use generators as functions to stop and resume code execution with the same stack. Hence, they can easily improve a web application’s performance by executing script in a customized order.
4. Error Handling
While writing web applications, programmers explore ways to identify and handle errors more efficiently. Koa.js both simplifies and improves error handling by using middleware more effectively. The built-in catchall for errors provided by the framework helps developers to prevent website crashes. The programmers can even use a simple ‘try/catch’ command to log errors without writing additional code. Koa.js even allows developers to customize error handling simply by changing the default setting.
5. Cascading Middleware
While using Node.js, programmers have to write additional code to streaming a file and closing the stream. But Koa.js helps programmers to avoid writing additional code by passing the file instead of streaming the file. A programmer can use the yield next command to yield requests downstream and send back responses upstream. He can further pass the streams manually according to his precise needs.
6. Router Module
Most web frameworks provide scripts, images, HTML pages, and other website resources through different routes. But the core module of Koa.js does not support routes. The web developers have to use Koa-router module to create multiple routes for various website resources. They can install the Koa-router module simply by running a command. The developers can even use the module to create both static and dynamic routes.
7. HTTP Methods
Koa.js identifies and understands the operation required by a client through HTTP methods like GET, POST, PUT and DELETE. Hence, the developers need to ensure that each request sent from the client includes the appropriate HTTP method. For instance, a request to retrieve data must contain the GET method, whereas a request sent to the server to accept enclosed data must include the POST method.
8. Request Object
Koa.js uses a request object developed on top of the vanilla request object provided by Node.js. But the request object uses by the framework accelerates HTTP server development by providing a number of additional functionality. The developers can even use the object to access various properties of a request — header, path, method and URL.
9. Response Object
The response object used by Koa.js is developed based on the vanilla response object provided by Node.js. But the Koa response object, like Koa request object, provides a number of additional functionality. The developers can even use the object to access important properties of a response — header, body, message and status.