Web Services

https://www.javatpoint.com/web-services-interview-questions

Rest Services

https://www.interviewbit.com/rest-api-interview-questions/

Rest

Rest is an architectural style that enables developers to build lightweight secure transactional web services which are used to modify the web resources accessed through URI.

Rest Principles:

REST defines 6 architectural constraints which make any web service – a true RESTful API.

·       Uniform interface

·       Client–server

·       Stateless

·       Cacheable

·       Layered system

·       Code on demand (optional)

Rest Features:

Rest uses appropriate HTTP Verbs

·       PUT

·       POST

·       GET

·       DELETE

·       PATCH

Rest uses hypermedia to handle the heterogenous client server communication.

Hypermedia: HATEOAS – Hypermedia as the engine of Application state

In the response, we can embed the link to the next resource.

1.     SOAP Vs REST

SOAP	REST
SOAP - Simple Object Access Protocol	REST - Representational State Transfer
SOAP is a protocol used to implement web services.	REST is an architectural design pattern for developing web services
SOAP cannot use REST as it is a protocol.	REST architecture can have SOAP protocol as part of the implementation.
SOAP specifies standards that are meant to be followed strictly.	REST defines standards but they need not be strictly followed.
SOAP client is more tightly coupled to the server which is similar to desktop applications having strict contracts.	The REST client is more flexible like a browser and does not depend on how the server is developed unless it follows the protocols required for establishing communication.
SOAP supports only XML transmission between the client and the server.	REST supports data of multiple formats like XML, JSON, MIME, Text, etc.
SOAP reads are not cacheable.	REST read requests can be cached.
SOAP uses service interfaces for exposing the resource logic.	REST uses URI to expose the resource logic.
SOAP is slower.	REST is faster.
Since SOAP is a protocol, it defines its own security measures.	REST only inherits the security measures based on what protocol it uses for the implementation.
SOAP is not commonly preferred, but they are used in cases which require stateful data transfer and more reliability.	REST is commonly preferred by developers these days as it provides more scalability and maintainability.

 

2.     While creating URI for web services, what are the best practices that needs to be followed?

Below is the list of best practices that need to be considered with designing URI for web services:

 

·       While defining resources, use plural nouns. Example: To identify user resource, use the name “users” for that resource.

·       While using the long name for resources, use underscore or hyphen. Avoid using spaces between words. For example, to define authorized users resource, the name can be “authorized_users” or “authorized-users”.

·       The URI is case-insensitive, but as part of best practice, it is recommended to use lower case only.

·       While developing URI, the backward compatibility must be maintained once it gets published. When the URI is updated, the older URI must be redirected to the new one using the HTTP status code 300.

·       Use appropriate HTTP methods like GET, PUT, DELETE, PATCH, etc. It is not needed or recommended to use these method names in the URI. Example: To get user details of a particular ID, use /users/{id} instead of /getUser

·       Use the technique of forward slashing to indicate the hierarchy between the resources and the collections. Example: To get the address of the user of a particular id, we can use: /users/{id}/address

 

3.     What are the best practices to develop RESTful web services?

 

·       Since REST supports multiple data formats, it is however good practice to develop REST APIs that accept and responds with JSON data format whenever possible. This is because a majority of the client and server technologies have inbuilt support to read and parse JSON objects with ease, thereby making JSON the standard object notation.

 

·       While naming the resource endpoints, ensure to use plural nouns and not verbs.

·       To represent the hierarchy of resources, use the nesting in the naming convention of the endpoints.

/authors/:id/address'

·       Error Handling should be done gracefully by returning appropriate error codes the application has encountered. HTTP Status codes that can be sent along with the response based on the scenario.

o   400 - Bad Request – client-side error - failed input validation.

o   401 - Unauthorized – The user is not authenticated and hence does not have authority to access the resource.

o   403 - Forbidden – User is authenticated but is not authorized to access the resource.

o   404 - Not Found – The resource is not found.

o   500 - Internal server error – This is a very generic server-side error that is thrown when the server goes down. This shouldn’t be returned by the programmer explicitly.

o   502 - Bad Gateway – Server did not receive a valid response from the upstream server.

o   503 - Service Unavailable – Some unexpected things happened

 

·       While retrieving huge resource data, it is advisable to include filtering and pagination of the resources. This is because returning huge data all at once can slow down the system and reduce the application performance

·       Good security practices are a must while developing REST APIs. The client-server communication must be private due to the nature of data sensitivity.

·       Since REST supports the feature of caching, we can use this feature to cache the data in order to improve the application performance.

·       Versioning needs to be done in case we are planning to make any changes with the existing endpoints. We do not want to break communication between our application and the apps that consume our application while we are working on the API release.

 

4.      What are Idempotent methods? How is it relevant in RESTful web services domain?

 

The meaning of idempotent is that even after calling a single request multiple times, the outcome of the request should be the same. While designing REST APIs, we need to keep in mind to develop idempotent APIs. This is because the consumers can write client-side code which can result in duplicate requests intentionally or not. Hence, fault-tolerant APIs need to be designed so that they do not result in erroneous responses.

 

5.     Can you tell what constitutes the core components of HTTP Request?

 

In REST, any HTTP Request has 5 main components, they are:

 

·       Method/Verb − This part tells what methods the request operation represents. Methods like GET, PUT, POST, DELETE, etc are some examples.

·       URI − This part is used for uniquely identifying the resources on the server.

·       HTTP Version − This part indicates what version of HTTP protocol you are using. An example can be HTTP v1.1.

·       Request Header − This part has the details of the request metadata such as client type, the content format supported, message format, cache settings, etc.

·       Request Body − This part represents the actual message content to be sent to the server.

 

6.     What constitutes the core components of HTTP Response?

 

·       Response Status Code − This represents the server response status code for the requested resource. Example- 400 represents a client-side error, 200 represents a successful response.

·       HTTP Version − Indicates the HTTP protocol version.

·       Response Header − This part has the metadata of the response message. Data can describe what is the content length, content type, response date, what is server type, etc.

·       Response Body − This part contains what is the actual resource/message returned from the server.

 

7.     PUT Vs POST

PUT	POST
PUT methods are used to request the server to store the enclosed entity in request. In case, the request does not exist, then new resource has to be created. If the resource exists, then the resource should get updated.	POST method is used to request the server to store the enclosed entity in the request as a new resource.
The URI should have a resource identifier. Example: PUT /users/{user-id}	The POST URI should indicate the collection of the resource. Example: POST /users
PUT methods are idempotent.	POST methods are not idempotent.
PUT is used when the client wants to modify a single resource that is part of the collection. If a part of the resource has to be updated, then PATCH needs to be used.	POST methods are used to add a new resource to the collection.
The responses are not cached here despite the idempotency.	Responses are not cacheable unless the response explicitly specifies Cache-Control fields in the header.
In general, PUT is used for UPDATE operations.	POST is used for CREATE operations.

 

8.     What makes REST services to be easily scalable?

 

REST services follow the concept of statelessness which essentially means no storing of any data across the requests on the server. This makes it easier to scale horizontally because the servers need not communicate much with each other while serving requests.

 

9.     Web Socket Vs Rest

REST	Web Socket
REST follows stateless architecture, meaning it won’t store any session-based data.	Web Socket APIs follow the stateful protocol as it necessitates session-based data storage.
The mode of communication is uni-directional. At a time, only the server or the client will communicate.	The communication is bi-directional, communication can be done by both client or server at a time.
REST is based on the Request-Response Model.	Web Socket follows the full-duplex model.
Every request will have sections like header, title, body, URL, etc.	Web sockets do not have any overhead and hence suited for real-time communication.
For every HTTP request, a new TCP connection is set up.	There will be only one TCP connection and then the client and server can start communicating.
REST web services support both vertical and horizontal scaling.	Web socket-based services only support vertical scaling.
REST depends on HTTP methods to get the response.	Web Sockets depend on the IP address and port number of the system to get a response.
Communication is slower here.	Message transmission happens very faster than REST API.
Memory/Buffers are not needed to store data here.	Memory is required to store data.

 

 

10.  What is a Resource in REST?

 

Any single item on the web can be considered as a resource like files, web pages and databases etc

 

11.  What is statelessness in RESTful Webservices?

 

The communication between client and server must be stateless. This means that each request from a service consumer should contain all the necessary information for the service to understand the meaning of the request, and all session state data should then be returned to the service consumer at the end of each request

12.  What are the advantages and disadvantages of statelessness in RESTful Webservices?

 

Advantages:

·       Web services can treat each method request independently.

·       Web services need not to maintain client’s previous interactions. It simplifies application design.

·       As HTTP is itself a statelessness protocol, RESTful Web services work seamlessly with HTTP protocol

Disadvantages:

·       Web services need to get extra information in each request and then interpret to get the client’s state in case client interactions are to be taken care of.

 

13.  What should be the purpose of OPTIONS and HEAD method of RESTful web services?

 

OPTIONS : list down the supported operations in a web service and should be read only.

HEAD : return only HTTP Header, no Body and should be read only.

 

14.  Can we implement transport layer security (TLS) in REST?

 

Yes, we can. TLS does the task of encrypting the communication between the REST client and the server and provides the means to authenticate the server to the client. It is used for secure communication as it is the successor of the Secure Socket Layer (SSL). HTTPS works well with both TLS and SSL thereby making it effective while implementing RESTful web services. One point to mention here is, the REST inherits the property of the protocol it implements. So security measures are dependent on the protocol REST implements.

 

15.  What is Payload in terms of RESTful web services?

 

Payload refers to the data passes in the request body. It is not the same as the request parameters. The payload can be sent only in POST methods as part of the request body.

 

16.  Is it possible to send payload in the GET and DELETE methods?

 

No, the payload is not the same as the request parameters. Hence, it is not possible to send payload data in these methods.

 

17.  How can you test RESTful Web Services?

 

RESTful web services can be tested using various tools like Postman, Swagger, etc

 

18.  What is the maximum payload size that can be sent in POST methods?

Theoretically, there is no restriction on the size of the payload that can be sent. But one must remember that the greater the size of the payload, the larger would be the bandwidth consumption and time taken to process the request that can impact the server performance.