Web service is a way to communicate between two applications over the network.

Some of the advantages of web services are:

1. Reusability: One web service can be used by many client applications at the same time.
2. Loosely Coupled: In Web services, clients code is totally independent with server code
3. Versioning: Multiple service versions can be running at same time.
4. Interoperability: Web services are accessible over the network and runs on HTTP/SOAP protocol and uses XML/JSON to transport data, hence it can be developed in any programming language.
5. Easy Deployment: Easy to deploy and integrate, just like web applications.

There are two types of web services:

1. SOAP Web Services
2. Restful Web Services

REST stands for Representational State Transfer.

REST is an architectural style that defines a set of constraints to be used for creating RESTful web services

Web services which follows 6 REST Architectural Constraints are called RESTful web services

Following are the 6 REST Architectural Constraints:

1. Uniform Interface
2. Client Server Architecture
3. Stateless
4. Cacheable
5. Layered System
6. Code on demand (optional)

1. 1. Uniform Interface:

      The uniform interface constraint defines the interface between clients and servers.
      The uniform interface constraint is fundamental to the design of any RESTful web services. It simplifies and decouples the architecture, which enables each part to evolve independently

There are four principles of the uniform interface:

1. 1. • Identifying the resource:

        Each resource must have a specific URI to be made available.

        • code
        • source

        1. //Get user detail by user_id
        2. GET https://www.fullstacktutorials.com/user/1
      • Resource representation:

        This shows how the resource will return to the client, resource representation can be in HTML, XML, JSON, TXT etc.

        • code
        • source

        1. //JSON format
        2. {
        3. “id”: “1”,
        4. “name”: “Full Stack Tutorials”,
        5. “age”: “25”,
        6. “status”: “active”
        7. }
      • Self-descriptive Messages:

        Each message includes enough information to describe how to process the message.

      • Hypermedia as the Engine of Application State (HATEOAS):
        • Client deliver state via body contents, query-string parameters, request headers and the requested URI (the resource name).
        • Server deliver state to clients via body content, response codes, and response headers.

        This is technically referred-to as hypermedia (or hyperlinks within hypertext)

   2. Client Server Architecture:
      • REST application should have a client-server architecture.
      • The client and server should act independently. The separation between the client and server improves portability of the client and scalability of the server.
   3. Stateless:

      No client session state on the server.

      Stateless means that the server doesn’t store any state about the client session on the server side.

      • Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all the information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have to send it again in subsequent request.
      • It’s easier to distribute a stateless application across load-balanced servers.
      • A stateless application is also easy to cache
      • There are actually two kinds of state. Application State that lives on the client and Resource State that lives on the server.
      • A web service only needs to care about your application state when you’re actually making a request

1. Cacheable:
   • Since many times APIs requesting the same resources, So it is necessary that these responses might be cached, avoiding unnecessary processing will significantly increase performance.
   • Caching partially or completely eliminates some client-server interactions, which further improves scalability and performance.
   • Caching can be implemented on the server or client side.
2. Layered System:
   • REST allows you to use a layered system architecture.
   • A layered system architecture means that there may be many things in between the client and the server.
   • Intermediaries servers such as proxy servers, load balancers, cache servers, gateways etc can be inserted between client and server to improve performance, security etc.

   #Example: In layered system architecture you deploy the APIs on server A, and store data on server B and authenticate requests in Server C. So, A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way.

3. Code on demand (optional):
   • It is optional.
   • An API/Web Services can be RESTful even without providing code on demand.
   • REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts etc.

   #Example: A clients may call an API to get any UI widget rendering code etc.

By Adopting all above 6 REST Architectural Constraints you can build a truly RESTful Web Services. If for some reasons you may skipped one or two constraints. Do not worry, you APIs or Web Services are still a RESTful Web Services – but not “truly RESTful”.

You may also like – MongoDB Interview Questions Answers

Following are the most popular HTTP Methods:

1. 1. GET – GET method is used to **read** (or retrieve) a representation of a resource. GET requests must be safe and idempotent.
   2. POST – POST method is mostly used to **create** new resources. it can also be used to update an resource.
   3. PUT – PUT is mostly used for **update** resources
   4. PATCH – PATCH is used for partial **modify** a resource.
   5. DELETE – DELETE is used to **delete** a resource identified by a URI.

1. HEAD – It returns meta information about the request URL.

PUT – PUT is used for updating resource. It is idempotent.

POST – POST is used for creating a new resource. It is not idempotent.

Idempotent means result of multiple successful request will not change state of resource after initial application

OR

An idempotent method means that the result of a successful performed request is independent of the number of times it is executed.

Difference is that when you want to update a resource with PUT method, you have to send the complete payload as the request whereas with PATCH, you only send the parameters which you want to update.

PUT (Complete replacement/update of a resource)- It is mandatory to send complete payload.

PATCH (Partial Update)- It requires only fields which we are going to update.

Suppose we have a resource that holds the first name and last name of a person.

{ “first_name”: “FullStack”, “last_name”: “Tutorials”, “age”: “23”, “status”: “active” }

If we want to change the first name then we send a PUT request for Update

Here, although we are only changing the first name, with PUT request we have to send the complete payload of that entity. In other words, it is mandatory to send all values again (complete payload)

When we send a PATCH request, however, we only send the data which we want to update. In other words, we only send the first name to update, no need to send the complete payload. this is the reason, PATCH request requires less bandwidth.

REST architecture treats every content as a resource.

Resources can be anything e.g. text files, HTML Pages, Images, Videos or any Dynamic Data.

RESTful web services make use of HTTP protocol as a medium of communication between client and server.

In REST Architecture, Resource can be represented in following ways:

1. JSON
2. XML
3. HTML
4. TEXT

Each HTTP request includes five key elements.

1. 1. HTTP Verbs which indicates HTTP methods such as GET, PUT, POST, and DELETE.
   2. URI stands for Uniform Resource Identifier (URI). It is the identifier for the resource on the server.
   3. HTTP Version which indicates HTTP version, for example-HTTP v1.1.
   4. Request Header carries metadata (as key-value pairs) for the HTTP Request message. Metadata could be a client (or browser) type, the format that client supports, message body format, and cache settings.

1. Request Body indicates the message content or resource representation.

Every HTTP response includes four key elements.

1. HTTP Version – Indicates HTTP version, for example-HTTP v1.1.
2. Response Header – Contains metadata for the HTTP response message stored in the form of key-value pairs. For example, content length, content type, response date, and server type.
3. Response Body – Indicates response message content or resource representation.
4. Status/Response Code – Indicates Server status for the resource present in the HTTP request.For example, 404 means resource not found and 200 means response is ok.

RESTful web services make use of HTTP protocol as a medium of communication between client and server. The client sends a message in the form of an HTTP Request. In response, the server transmits the HTTP Response. This technique is called Messaging. These messages contain message data and metadata i.e. information about the message itself.

This method lists down all the operations a web service supports. It makes read-only requests to the server.

URI stands for Uniform Resource Identifier. In REST architecture, URI is the identifier for the Resource.

The purpose of a URI is to locate a resource(s) on the server hosting the web service

Following are some most popular and most frequently used tools that can help in testing the SOAP and RESTful web services.

1. SOAP UI tool.
2. Postman extension for Chrome.
3. Poster for Firefox browser.

Generally, REST web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats.

Whereas, SOAP is preferred where services require an advanced level of security and transactional reliability.

1. Does the service expose data or business logic? To expose data REST will be a better choice and SOAP for logic.
2. If the consumer or the service providers require a formal contract, then SOAP can provide such a contract via WSDL.
3. Need to support multiple data formats. REST supports this.
4. Support for AJAX calls. REST can use the XMLHttpRequest.
5. Synchronous and asynchronous calls – SOAP enables both synchronous/asynchronous operations whereas REST has built-in support for synchronous.
6. Stateless or Stateful calls -REST is suited for stateless operations.

1. Security requirement – SOAP provides a high level of security.
2. Transaction support – SOAP has good support for transaction management.
3. Limited bandwidth – SOAP has a lot of overhead when sending/receiving packets since it’s XML based, requires a SOAP header. However, REST requires less bandwidth to send requests to the server. Its messages are mostly built using JSON.
4. Ease of use – It is easy to implement, test, and maintain REST based application.

You may also like – JavaScript Interview Questions Answers

“Microservices is a phenomenon of building applications as a collection of multiple independent services which are loosely coupled”.

Microservices is an Architectural Patterns which decompose the application into various modules which are independent of each other.

1. Reusability – Once a module developed can be used multiple times.
2. Maintainability – Easy to maintain.
3. Technology Independent – There is no need of working with single technology for the entire application as like of monolithic kernel.Various technologies can be used to build the application and it makes developers to comfortably work as their interest.
4. Deployment – The primary advantage of Microservices is that the modules can be independently deployed.

• Uniform Resource Identifier (URI) is a string of characters used to identify a resource on the Internet
• An URI identifies a resource either by location, or a name, or both. A URI has two specializations known as URL and URN

• An Uniform Resource Locator (URL) is a subset of the Uniform Resource Identifier (URI).
• An Uniform Resource Locator (URL) contains information about how to fetch a resource from its location.
• An URL may be http, https, ftp etc.

#Example:

• https://www.fullstacktutorials.com/interviews/restful-web-services-interview-questions-26.html
• ftp://fullstacktutorials.com/restfulapis.zip

• An Uniform Resource Name (URN) is a subset of the Uniform Resource Identifier (URI).
• URN Identifies a resource by name
• It always starts with the prefix urn:

#Example:

• urn:isbn:0123456759 to identify a book by its ISBN number

Swagger is a set of open-source tools built around the OpenAPI Specification that can help you design, build, document and consume REST APIs.

• Swagger Editor – browser-based editor where you can write OpenAPI specs.
• Swagger UI – renders OpenAPI specs as interactive API documentation.
• Swagger Codegen – generates server stubs and client libraries from an OpenAPI spec.

OpenAPI Specification (formerly Swagger Specification) is an API description format for REST APIs.

Following are the list of some most frequenlty used HTTP status codes

About Author

Reetesh Gupta

administrator

See author's posts