Explore topic-wise InterviewSolutions in .

• Safe methods are those that do not change any resources internally. These methods can be cached and can be RETRIEVED without any effects on the resource.
• IDEMPOTENT methods are those methods that do not change the responses to the resources EXTERNALLY. They can be called multiple TIMES without any change in the responses.

According to restcookbook.com, the following is the table that describes what methods are idempotent and what is safe.

While implementing Basic Authentication as part of APIs, the user MUST provide the username and password which is then concatenated by the browser in the form of “username: password” and then perform BASE64 encoding on it. The ENCODED value is then SENT as the value for the “Authorization” HEADER on every HTTP request from the browser. Since the credentials are only encoded, it is advised to use this form when requests are sent over HTTPS as they are not secure and can be intercepted by anyone if secure protocols are not used.

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.

RESTful web services can be tested using various TOOLS like Postman, Swagger, etc. Postman provides a LOT of features like sending requests to endpoints and show the RESPONSE which can be CONVERTED to JSON or XML and also provides features to inspect request parameters like headers, query parameters, and also the response headers. Swagger also provides similar features like Postman and it provides the facility of documentation of the endpoints too. We can also use tools like Jmeter for performance and load testing of APIs.

No, the PAYLOAD is not the same as the request parameters. HENCE, it is not POSSIBLE to SEND payload data in these methods.

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.

There is no NEED to EXPLICITLY MAKING the RESOURCES thread-safe because, upon every request, new resource instances are created which makes them thread-safe by DEFAULT.

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.

The request FLOW difference between the REST and Web Socket is shown below:

REST services have gained popularity due to the nature of simplicity, scalability, faster speed, improved performance, and multiple data format support. But, SOAP has its own advantages too. DEVELOPERS use SOAP where the services require advanced security and reliability.

Following are the questions you need to ask to help you decide which service can be used:

• Do you want to expose resource data or business logic?
  • SOAP is commonly used for exposing business logic and REST for exposing data.
• Does the client require a formal strict contract?
  • If yes, SOAP provides strict CONTRACTS by using WSDL. Hence, SOAP is preferred here.
• Does your service require support for multiple formats of data?
  • If yes, REST supports multiple data formats which is why it is preferred in this case.
• Does your service require AJAX call support?
  • If yes, REST can be used as it provides the XMLHttpRequest.
• Does your service require both synchronous and asynchronous requests?
  • SOAP has support for both sync/async operations.
  • REST only supports synchronous calls.
• Does your service require statelessness?
  • If yes, REST is suitable. If no, SOAP is preferred.
• Does your service require a high-security level?
  • If yes, SOAP is preferred. REST inherits the security PROPERTY based on the underlying implementation of the protocol. Hence, it can’t be preferred at all times.
• Does your service require support for transactions?
  • If yes, SOAP is preferred as it is good in providing advanced support for TRANSACTION management.
• What is the bandwidth/resource required?
  • SOAP involves a lot of overhead while sending and receiving XML data, hence it consumes a lot of bandwidth.
  • REST makes use of less bandwidth for data transmission.
• Do you want services that are easy to develop, test, and maintain frequently?
  • REST is known for simplicity, hence it is preferred.

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.

Addressing is the process of locating a single/multiple resources that are PRESENT on the SERVER. This task is accomplished by MAKING use of URI (Uniform Resource Identifier). The general format of URI is 

HTTP Response has 4 components:

• 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.

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.

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.

• Idempotent methods ensure that the responses to a request if called once or ten times or more than that remain the same. This is EQUIVALENT to adding any NUMBER with 0.
• REST provides idempotent methods automatically. GET, PUT, DELETE, HEAD, OPTIONS, and TRACE are the idempotent HTTP methods. POST is not idempotent.
  • POST is not idempotent because POST APIs are usually used for creating a new resource on the server. While calling POST methods N times, there will be N new resources. This does not result in the same outcome at a time.
  • Methods like GET, OPTIONS, TRACE, and HEAD are idempotent because they do not change the state of resources on the server. They are meant for resource retrieval whenever called. They do not result in write operations on the server thereby making it idempotent.
  • PUT methods are generally used for updating the state of resources. If you call PUT methods N times, the first request updates the resource and the subsequent requests will be overwriting the same resource again and again without changing anything. Hence, PUT methods are idempotent.
  • DELETE methods are said to be idempotent because when calling them for N times, the first request results in successful deletion (Status Code 200), and the next subsequent requests result in nothing - Status Code 204. The response is different, but there is no change of resources on the server-side.
    • However, if you are attempting to delete the resource present, at last, EVERY time you hit the API, such as the request DELETE /user/last which deletes the last user record, then calling the request N times would delete N resources on the server. This does not make DELETE idempotent. In such cases, as part of good practices, it is advisable to use POST requests.

RESTful web services use REST API as means of implementation using the HTTP protocol. REST API is nothing but an application programming interface that follows REST architectural constraints such as statelessness, cacheability, maintainability, and scalability. It has become very popular among the developer community due to its simplicity. Hence, it is very important to develop safe and secure REST APIs that follow good conventions. Below are some best practices for developing REST APIs:

• 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.
  • To ensure that the application responds using JSON data format, the response header should have Content-Type set to as application/JSON, this is because certain HTTP clients look at the value of this response header to parse the objects appropriately.
  • To ensure that the request sends the data in JSON format, again the Content-Type must be set to application/JSON on the request header.
• While naming the resource endpoints, ensure to use plural nouns and not verbs. The API endpoints should be clear, brief, easy to understand, and informative. Using verbs in the resource name doesn’t contribute much information because an HTTP request already has what the request is doing in its HTTP method/verb. An appropriate HTTP verb should be used to represent the TASK of the API endpoint.
  • Below are the most commonly used HTTP methods to define the verb:
    • GET - indicates get/retrieve the resource data
    • POST - indicates create new resource data
    • PUT - indicates update the existing resource data
    • DELETE - indicates remove the resource data
• To represent the hierarchy of resources, use the nesting in the naming convention of the endpoints. In case, you want to retrieve data of one object residing in another object, the endpoint should reflect this to communicate what is happening. For example, to get the address of an author, we can use the GET method for the URI /authors/:id/address'
  • Please ensure there are no more than 2 or 3 levels of nesting as the name of the URI can become too long and unwieldy.
• Error Handling should be done gracefully by returning appropriate error codes the application has encountered. REST has defined standard HTTP Status codes that can be sent along with the response based on the scenario.
  • Error codes should also be accompanied by appropriate error messages that can help the developers to take corrective actions. However, the message should not be too elaborate as well which can help the hacker to hack your application.
  • Common status codes are:
    • 400 - Bad Request – client-side error - failed input validation.
    • 401 - Unauthorized – The user is not authenticated and hence does not have authority to access the resource.
    • 403 - Forbidden – User is authenticated but is not authorized to access the resource.
    • 404 - Not Found – The resource is not found.
    • 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.
    • 502 - Bad Gateway – Server did not receive a valid response from the upstream server.
    • 503 - Service Unavailable – Some unexpected things happened on the server such as system failure, overload, etc.
• 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. Hence, filter some items reduces the data to some extent. Pagination of data is done to ensure only some results are sent at a time. Doing this can increase the server performance and reduce the burden of the server resources.
• Good security practices are a must while developing REST APIs. The client-server communication must be private due to the nature of data sensitivity. Hence, incorporating SSL/TLS becomes the most important step while developing APIs as they facilitate establishing secure communication. SSL certificates are easier to get and load on the server.
  • Apart from the secure channels, we need to ensure that not everyone should be able to access the resource. For example, normal users should not access the data of admins or another user. Hence, role-based access controls should be in place to make sure only the right set of users can access the right set of data.
• Since REST supports the feature of caching, we can use this feature to cache the data in order to improve the application performance. Caching is done to avoid querying the database for a request repeated times. Caching makes data retrieval fast. However, care must be taken to ensure that the cache has updated data and not outdated ones. Frequent cache update measures need to be incorporated. There are many cache providers like Redis that can assist in caching.
• API Versioning: 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. The transition has to be seamless. Semantic versioning can be followed. For example, 3.0.1 represents 3rd major version with the first patch. Usually, in the API endpoints, we define /v1,/v2, etc at the beginning of the API path.

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