In the software development industry, integrations play a key role in application design. One of the main technologies for this is the REST API. Knowledge of the REST API is an important skill for every tech specialist. In this article, we will present 25 REST API questions that will help you prepare for a job interview and improve your skills. Enjoy reading! First of all, the interviewer usually divides questions on REST API into theoretical and practical. First, they ask 2-3 theoretical questions on terminology and HTTP request methods, and then you receive a practical task on drawing up a request. This article contains frequently asked theoretical questions, and I plan to publish examples of practical tasks related to REST API in the next article. We do not know in advance what questions you will get at an interview, but I am sure that in the process of working through our list of typical questions, you will probably dive deeper into the topic, and improve your knowledge of the REST API in any case. Now, let's go from simple to complex, starting with basic terminology and continuing with a section with more complex questions. 1. What is REST? Answer: There are three terms used when referring to REST that are often considered to be the same thing, but this is not entirely true. These terms are REST, REST API, and RESTful API. Now there will be an answer about REST, the term stands for Representational State Transfer and is an architectural style based on the HTTP protocol (Hypertext Transfer Protocol) for developing applications that have a front-end and/or integration with external systems. REST describes guidelines that API services that are designed should follow. These principles ensure that requests are passed between client and server using HTTP. 2. What is REST API? Answer: An API is a programming interface that allows individual applications to communicate and exchange data. For example, a food delivery app can use the Google Maps API to track the courier's location and display it on a map. A REST API is an API that follows the principles of REST, treating all data as resources, each represented by a unique Uniform Resource Identifier (URI). 3. What is a RESTful API? Answer: A RESTful API is an API designed according to the rules (or you can also say “principles”) of REST. In other words, the difference between REST API and RESTful API is terminological. The first case refers to a set of REST rules, and the second refers to the implementation of a specific API following REST rules. The term RESTful API is often replaced with REST API or even REST purely for the sake of brevity. When system analysts draw arrows labeled REST on an application diagram, they mean a RESTful API. 4. What are the two main principles of REST? Answer: REST API requests must follow two basic principles: Separation into client and server: The interaction between the client and the server is carried out in the form of requests and responses. Only clients can make requests and only servers can send responses to work independently of each other. Single protocol: Interaction between the client and server must be carried out using a single protocol. For REST, this protocol is HTTP. 5. What other principles of REST do you know? Answer: You can name at least 4 more principles. REST API requests do not store state on the server and can pass through layers of servers and be cached. You can also send executable code to clients in the server response. Server Stateless: The server does not store any information about past requests/responses. Each request and response contains all the information needed to complete the interaction. Stateless communication reduces server load, saves memory, and improves performance. Layered system: Additional servers are possible between the client and the API server in the form of layers to perform different functions. In a system built on REST principles, layers are modular and can be added and removed without affecting communications between the client and server. Cacheability: The server's responses indicate whether its resource is cacheable so that clients can cache any resource to improve performance. Code on demand: The server can send executable code to clients in its response for execution within the client application. 6. What is a resource? Answer: In REST, every accessible object on the server side is designated as a resource. A resource is an object that has a type, data associated with it, a relationship to other resources on the server, and a list of methods that can be used to work with it. For example, a resource could be an HTML or text file, a data file, an image or video, or an executable code file. A resource is identified by a Uniform Resource Identifier or URI. Clients access resources by using their URIs in HTTP requests. 7. What is a URL? Answer: URI stands for Uniform Resource Identifier. This is a string that identifies a resource on the server. Each resource has its own unique URI, which, when included in an HTTP request, allows clients to access and perform actions on that resource. The process of referring to a resource by its URI is called "addressing". 8. What is CRUD? Answer: CRUD stands for "Create, Read, Update, Delete". These are the four main actions that can be performed on databases via the REST API. Each action has its own HTTP request method: Create = POST Read = GET Update = PUT Delete = DELETE 9. What is meant by the payload in the server response? Answer: The HTTP response payload refers to the resource data that was requested by the client. This is also briefly called "HTTP response payload". This data can be in JSON, XML, HTML, images, files, and so on, depending on what exactly the server provides. 10. What is REST messaging? Answer: Messaging in REST refers to the exchange of messages between the client and the server. Communication always begins with the client making an HTTP request to the server. The server processes this request and then sends back an HTTP response that indicates the status of the request and any resources that the client requested. 11. What is a message broker in REST? Answer: In the context of REST, the term "message broker" is a middleware that serves to pass messages between various components or systems in a distributed application. The broker can provide asynchronous data exchange, message queuing, and message processing between various system modules. Message brokers can be used to manage asynchronous operations or send notifications. The message broker is not a native REST element because... REST focuses on synchronous communication between client and server using HTTP requests. 12. What HTTP request methods are supported by REST? Answer: The HTTP request method specifies the desired action that the server will perform on the resource. In REST, there are four main methods for making HTTP requests from a client to a server: GET: Requests a resource from the server, this method is read-only. POST: Creates a new resource on the server. PUT: Updates an existing resource on the server. DELETE: Deletes a resource from the server. 13. What is the difference between the POST and PUT methods? Answer: POST is for creating a resource on the server while PUT is for replacing a resource at a specific URI with another resource. If you use PUT on a URI that already has a resource associated with it, PUT will replace it. If there is no resource at the specified URI, PUT creates one. PUT is idempotent, meaning calling it multiple times will result in only one resource being created. This happens because each call replaces an existing resource (or creates a new one if there is nothing to replace). POST is not idempotent. If, for example, you call POST 10 times, then 10 different resources will be created on the server, each with its own URI. Although rarely used, POST responses can be cached, but PUT responses cannot. POST requests are generally considered uncacheable, but they can be cached when they contain clear information about the “freshness” of the data. A more detailed answer is that the response for a POST (or PATCH) request can be cached if the data is "fresh" and the Content-Location (en-US) header is set, but this is rarely implemented. Therefore, POST caching should be avoided if possible. 14. What are the main parts of an HTTP request? Answer: In REST, there are the following basic components of an HTTP request: The request method that will be made to the resource (i.e. GET, POST, PUT, DELETE). A URI that identifies the requested resource on the server. HTTP version – i.e. what version should be in the server response. The HTTP request header contains metadata about the request, such as the user agent, file formats accepted by the client, request body format, language, caching preferences, etc. The body of an HTTP request, it contains all the data associated with the request. This is only necessary if the request is to change data on the server using the POST or PUT methods. 15. What are the main parts of an HTTP response? Answer: HTTP responses are sent from the server to the client. They inform the client that the requested action has (or has not) been completed and the delivery of any requested resources. There are four main components of an HTTP response: HTTP version used. Status bar with request status and HTTP response status code. HTTP response header with metadata about the response, including time, server name, user agent, returned resource file formats, caching information. HTTP response body containing data about the resource that was requested by the client 16. Name at least 3 codes for successful HTTP server responses Answer: The server returns the following operation status codes when the request is successfully processed: 200 OK: The request was completed successfully. 201 Created: The request was successful and the resource was created. 202 Accepted: This status means that the server has accepted the client's request but has not completed processing it. Processing can be asynchronous. 17. Name at least 4 server HTTP response codes when redirecting a request Answer: The server returns the following status codes when redirecting a request: 301 Moved Permanently: This status tells the client that the requested resource has been permanently moved to another URL and the client must access the new URL to access the resource. 302 Found: This status indicates that the resource has been temporarily moved to another URL and the client should temporarily use the new URL. 307 Temporary Redirect: Similar to 302, but the client must use the same request method when accessing the new URL. 308 Permanent Redirect: Similar to 301, but the client must use the same request method when accessing the new URL 18. Name at least 4 codes for unsuccessful HTTP server responses. Answer: The server returns the following codes when the request is unsuccessful: 400 Bad Request: The request was not completed due to an error in the request, such as a typo or missing data. 401 Unauthorized: The request was not completed because the client is not authenticated or does not have permission to access the requested resource. 403 Forbidden: The request was not completed because the client is authenticated but not authorized to access the requested resource. 404 Not Found: The request was not completed because the server could not find the requested resource. 19. Name at least 3 server error codes. Answer: The server returns the following codes when there is an error on the server: 500 Internal Server Error: The request was not completed due to an unexpected problem with the server. 502 Bad Gateway: The request was not completed due to an incorrect response from the upstream server. 503 Service Unavailable: The server was unable to process the request due to maintenance, overload, or other temporary disturbances. You can find a list of the most common HTTP codes is here 20. What is the difference between REST and GraphQL Answer: GraphQL is a query language that allows clients to query only the data they need. In GraphQL, the client defines the structure and format of the data it wants to receive, and the server returns it according to that request. The key difference is that REST has a fixed request and response format for each resource, while GraphQL allows clients to define their request and get only the information they need, making it more efficient and flexible to use. 21. What is the difference between REST and SOAP? Answer: REST and SOAP (Simple Object Access Protocol) are two approaches to building APIs. There are 3 main differences between them: SOAP is a strict protocol for building secure APIs. REST is not a protocol, but an architectural style dictated by a set of guidelines called REST principles. - REST APIs are simpler to build, lighter, and generally faster than SOAP APIs. SOAP APIs are considered more secure than REST APIs, although REST APIs can still implement security features to make them quite secure. - REST allows responses to be cached, while SOAP does not. SOAP encodes data in XML format. - REST allows you to encode data in any format, although XML and JSON are the most popular. 22. What is the difference between REST and AJAX? Answer: Asynchronous JavaScript or AJAX is a set of web development technologies used in web applications. At its core, AJAX allows a web page to make requests to the server and update the page's interface without having to update the entire page. An AJAX client can use the REST API in its requests, but AJAX does not have to work only with the REST API. REST APIs can communicate with any client, whether it uses AJAX or not. Unlike REST, which uses HTTP requests and responses to exchange messages, AJAX sends its requests to the server using the XMLHttpRequest object built into JavaScript. Server responses are executed by the page's JavaScript code to change its content. 23. What is the "Contract First" approach to REST API development? Answer: The Contract First approach to REST API development is a methodology in which the API specification and contract are created and defined before the actual development begins. This contract serves as an important document that defines how clients can interact with the API and what expected results will be obtained from various requests. 24. What are the benefits of Contract First? Answer: The following advantages of the Contract First approach can be mentioned: Clear API Definition: The API specification and contract define how the API should interact with clients. Reduce Risks: Preliminary contract approval with customers helps reduce the risk of misunderstandings and failure to meet API development expectations. Improved documentation: The contract text often serves as documentation for the API, making it easier to use and integrate. 25. What is the Code First approach to REST API development? Answer: The Code First approach to REST API development is a methodology in which the API functionality is first developed and then an API specification is automatically generated based on that functionality. The hallmark of the Code First approach is that developers focus on writing the API logic and use tools that allow them to automatically create documentation and specifications based on that logic. In general, both approaches, Code First and Contract First, can be combined within the same API development project. In this case, Code First is used for rapid prototyping, followed by Contract First to formalize the contract. I hope this article is helpful for you in preparation for a job interview or in refreshing your knowledge about REST API. In the software development industry, integrations play a key role in application design. One of the main technologies for this is the REST API . Knowledge of the REST API is an important skill for every tech specialist. In this article, we will present 25 REST API questions that will help you prepare for a job interview and improve your skills. Enjoy reading! software development REST API First of all, the interviewer usually divides questions on REST API into theoretical and practical. First, they ask 2-3 theoretical questions on terminology and HTTP request methods, and then you receive a practical task on drawing up a request. This article contains frequently asked theoretical questions, and I plan to publish examples of practical tasks related to REST API in the next article. We do not know in advance what questions you will get at an interview, but I am sure that in the process of working through our list of typical questions, you will probably dive deeper into the topic, and improve your knowledge of the REST API in any case. Now, let's go from simple to complex, starting with basic terminology and continuing with a section with more complex questions. 1. What is REST? Answer: There are three terms used when referring to REST that are often considered to be the same thing, but this is not entirely true. These terms are REST, REST API, and RESTful API. Now there will be an answer about REST, the term stands for Representational State Transfer and is an architectural style based on the HTTP protocol (Hypertext Transfer Protocol) for developing applications that have a front-end and/or integration with external systems. REST describes guidelines that API services that are designed should follow. These principles ensure that requests are passed between client and server using HTTP. 2. What is REST API? Answer: An API is a programming interface that allows individual applications to communicate and exchange data. For example, a food delivery app can use the Google Maps API to track the courier's location and display it on a map. A REST API is an API that follows the principles of REST, treating all data as resources, each represented by a unique Uniform Resource Identifier (URI). 3. What is a RESTful API? Answer: A RESTful API is an API designed according to the rules (or you can also say “principles”) of REST. In other words, the difference between REST API and RESTful API is terminological. The first case refers to a set of REST rules, and the second refers to the implementation of a specific API following REST rules. The term RESTful API is often replaced with REST API or even REST purely for the sake of brevity. When system analysts draw arrows labeled REST on an application diagram, they mean a RESTful API. 4. What are the two main principles of REST? Answer: REST API requests must follow two basic principles: Separation into client and server: The interaction between the client and the server is carried out in the form of requests and responses. Only clients can make requests and only servers can send responses to work independently of each other. Single protocol: Interaction between the client and server must be carried out using a single protocol. For REST, this protocol is HTTP. 5. What other principles of REST do you know? Answer: You can name at least 4 more principles. REST API requests do not store state on the server and can pass through layers of servers and be cached. You can also send executable code to clients in the server response. Server Stateless: The server does not store any information about past requests/responses. Each request and response contains all the information needed to complete the interaction. Stateless communication reduces server load, saves memory, and improves performance. Layered system: Additional servers are possible between the client and the API server in the form of layers to perform different functions. In a system built on REST principles, layers are modular and can be added and removed without affecting communications between the client and server. Cacheability: The server's responses indicate whether its resource is cacheable so that clients can cache any resource to improve performance. Code on demand: The server can send executable code to clients in its response for execution within the client application. 6. What is a resource? Answer: In REST, every accessible object on the server side is designated as a resource. A resource is an object that has a type, data associated with it, a relationship to other resources on the server, and a list of methods that can be used to work with it. For example, a resource could be an HTML or text file, a data file, an image or video, or an executable code file. A resource is identified by a Uniform Resource Identifier or URI. Clients access resources by using their URIs in HTTP requests. 7. What is a URL? Answer: URI stands for Uniform Resource Identifier. This is a string that identifies a resource on the server. Each resource has its own unique URI, which, when included in an HTTP request, allows clients to access and perform actions on that resource. The process of referring to a resource by its URI is called "addressing". 8. What is CRUD? Answer: CRUD stands for "Create, Read, Update, Delete". These are the four main actions that can be performed on databases via the REST API. Each action has its own HTTP request method: Create = POST Read = GET Update = PUT Delete = DELETE Create = POST Read = GET Update = PUT Delete = DELETE 9. What is meant by the payload in the server response? Answer: The HTTP response payload refers to the resource data that was requested by the client. This is also briefly called "HTTP response payload". This data can be in JSON, XML, HTML, images, files, and so on, depending on what exactly the server provides. 10. What is REST messaging? Answer: Messaging in REST refers to the exchange of messages between the client and the server. Communication always begins with the client making an HTTP request to the server. The server processes this request and then sends back an HTTP response that indicates the status of the request and any resources that the client requested. 11. What is a message broker in REST? Answer: In the context of REST, the term "message broker" is a middleware that serves to pass messages between various components or systems in a distributed application. The broker can provide asynchronous data exchange, message queuing, and message processing between various system modules. Message brokers can be used to manage asynchronous operations or send notifications. The message broker is not a native REST element because... REST focuses on synchronous communication between client and server using HTTP requests. 12. What HTTP request methods are supported by REST? Answer: The HTTP request method specifies the desired action that the server will perform on the resource. In REST, there are four main methods for making HTTP requests from a client to a server: GET: Requests a resource from the server, this method is read-only. POST: Creates a new resource on the server. PUT: Updates an existing resource on the server. DELETE: Deletes a resource from the server. GET: Requests a resource from the server, this method is read-only. POST: Creates a new resource on the server. PUT: Updates an existing resource on the server. DELETE: Deletes a resource from the server. 13. What is the difference between the POST and PUT methods? Answer: POST is for creating a resource on the server while PUT is for replacing a resource at a specific URI with another resource. If you use PUT on a URI that already has a resource associated with it, PUT will replace it. If there is no resource at the specified URI, PUT creates one. PUT is idempotent, meaning calling it multiple times will result in only one resource being created. This happens because each call replaces an existing resource (or creates a new one if there is nothing to replace). POST is not idempotent. If, for example, you call POST 10 times, then 10 different resources will be created on the server, each with its own URI. Although rarely used, POST responses can be cached, but PUT responses cannot. POST requests are generally considered uncacheable, but they can be cached when they contain clear information about the “freshness” of the data. A more detailed answer is that the response for a POST (or PATCH) request can be cached if the data is "fresh" and the Content-Location (en-US) header is set, but this is rarely implemented. Therefore, POST caching should be avoided if possible. 14. What are the main parts of an HTTP request? Answer: In REST, there are the following basic components of an HTTP request: The request method that will be made to the resource (i.e. GET, POST, PUT, DELETE). A URI that identifies the requested resource on the server. HTTP version – i.e. what version should be in the server response. The HTTP request header contains metadata about the request, such as the user agent, file formats accepted by the client, request body format, language, caching preferences, etc. The body of an HTTP request, it contains all the data associated with the request. This is only necessary if the request is to change data on the server using the POST or PUT methods. 15. What are the main parts of an HTTP response? Answer: HTTP responses are sent from the server to the client. They inform the client that the requested action has (or has not) been completed and the delivery of any requested resources. There are four main components of an HTTP response: HTTP version used. Status bar with request status and HTTP response status code. HTTP response header with metadata about the response, including time, server name, user agent, returned resource file formats, caching information. HTTP response body containing data about the resource that was requested by the client 16. Name at least 3 codes for successful HTTP server responses Answer: The server returns the following operation status codes when the request is successfully processed: 200 OK: The request was completed successfully. 201 Created: The request was successful and the resource was created. 202 Accepted: This status means that the server has accepted the client's request but has not completed processing it. Processing can be asynchronous. 200 OK: The request was completed successfully. 201 Created: The request was successful and the resource was created. 202 Accepted: This status means that the server has accepted the client's request but has not completed processing it. Processing can be asynchronous. 17. Name at least 4 server HTTP response codes when redirecting a request Answer: The server returns the following status codes when redirecting a request: 301 Moved Permanently: This status tells the client that the requested resource has been permanently moved to another URL and the client must access the new URL to access the resource. 302 Found: This status indicates that the resource has been temporarily moved to another URL and the client should temporarily use the new URL. 307 Temporary Redirect: Similar to 302, but the client must use the same request method when accessing the new URL. 308 Permanent Redirect: Similar to 301, but the client must use the same request method when accessing the new URL 301 Moved Permanently: This status tells the client that the requested resource has been permanently moved to another URL and the client must access the new URL to access the resource. 302 Found: This status indicates that the resource has been temporarily moved to another URL and the client should temporarily use the new URL. 307 Temporary Redirect: Similar to 302, but the client must use the same request method when accessing the new URL. 308 Permanent Redirect: Similar to 301, but the client must use the same request method when accessing the new URL 18. Name at least 4 codes for unsuccessful HTTP server responses. Answer: The server returns the following codes when the request is unsuccessful: 400 Bad Request: The request was not completed due to an error in the request, such as a typo or missing data. 401 Unauthorized: The request was not completed because the client is not authenticated or does not have permission to access the requested resource. 403 Forbidden: The request was not completed because the client is authenticated but not authorized to access the requested resource. 404 Not Found: The request was not completed because the server could not find the requested resource. 400 Bad Request: The request was not completed due to an error in the request, such as a typo or missing data. 401 Unauthorized: The request was not completed because the client is not authenticated or does not have permission to access the requested resource. 403 Forbidden: The request was not completed because the client is authenticated but not authorized to access the requested resource. 404 Not Found: The request was not completed because the server could not find the requested resource. 19. Name at least 3 server error codes. Answer: The server returns the following codes when there is an error on the server: 500 Internal Server Error: The request was not completed due to an unexpected problem with the server. 502 Bad Gateway: The request was not completed due to an incorrect response from the upstream server. 503 Service Unavailable: The server was unable to process the request due to maintenance, overload, or other temporary disturbances. 500 Internal Server Error: The request was not completed due to an unexpected problem with the server. 500 Internal Server Error: The request was not completed due to an unexpected problem with the server. 502 Bad Gateway: The request was not completed due to an incorrect response from the upstream server. 502 Bad Gateway: The request was not completed due to an incorrect response from the upstream server. 503 Service Unavailable: The server was unable to process the request due to maintenance, overload, or other temporary disturbances. 503 Service Unavailable: The server was unable to process the request due to maintenance, overload, or other temporary disturbances. You can find a list of the most common HTTP codes is here You can find a list of the most common HTTP codes is here You can find a list of the most common HTTP codes is here here 20. What is the difference between REST and GraphQL Answer: GraphQL is a query language that allows clients to query only the data they need. In GraphQL, the client defines the structure and format of the data it wants to receive, and the server returns it according to that request. The key difference is that REST has a fixed request and response format for each resource, while GraphQL allows clients to define their request and get only the information they need, making it more efficient and flexible to use. 21. What is the difference between REST and SOAP? Answer: REST and SOAP (Simple Object Access Protocol) are two approaches to building APIs. There are 3 main differences between them: SOAP is a strict protocol for building secure APIs. REST is not a protocol, but an architectural style dictated by a set of guidelines called REST principles. - REST APIs are simpler to build, lighter, and generally faster than SOAP APIs. SOAP APIs are considered more secure than REST APIs, although REST APIs can still implement security features to make them quite secure. - REST allows responses to be cached, while SOAP does not. SOAP encodes data in XML format. - REST allows you to encode data in any format, although XML and JSON are the most popular. SOAP is a strict protocol for building secure APIs. REST is not a protocol, but an architectural style dictated by a set of guidelines called REST principles. - REST APIs are simpler to build, lighter, and generally faster than SOAP APIs. SOAP APIs are considered more secure than REST APIs, although REST APIs can still implement security features to make them quite secure. - REST allows responses to be cached, while SOAP does not. SOAP encodes data in XML format. - REST allows you to encode data in any format, although XML and JSON are the most popular. 22. What is the difference between REST and AJAX? Answer: Asynchronous JavaScript or AJAX is a set of web development technologies used in web applications. At its core, AJAX allows a web page to make requests to the server and update the page's interface without having to update the entire page. An AJAX client can use the REST API in its requests, but AJAX does not have to work only with the REST API. REST APIs can communicate with any client, whether it uses AJAX or not. Unlike REST, which uses HTTP requests and responses to exchange messages, AJAX sends its requests to the server using the XMLHttpRequest object built into JavaScript. Server responses are executed by the page's JavaScript code to change its content. 23. What is the "Contract First" approach to REST API development? Answer: The Contract First approach to REST API development is a methodology in which the API specification and contract are created and defined before the actual development begins. This contract serves as an important document that defines how clients can interact with the API and what expected results will be obtained from various requests. 24. What are the benefits of Contract First? Answer: The following advantages of the Contract First approach can be mentioned: Clear API Definition: The API specification and contract define how the API should interact with clients. Reduce Risks: Preliminary contract approval with customers helps reduce the risk of misunderstandings and failure to meet API development expectations. Improved documentation: The contract text often serves as documentation for the API, making it easier to use and integrate. Clear API Definition: The API specification and contract define how the API should interact with clients. Reduce Risks: Preliminary contract approval with customers helps reduce the risk of misunderstandings and failure to meet API development expectations. Improved documentation: The contract text often serves as documentation for the API, making it easier to use and integrate. 25. What is the Code First approach to REST API development? Answer: The Code First approach to REST API development is a methodology in which the API functionality is first developed and then an API specification is automatically generated based on that functionality. The hallmark of the Code First approach is that developers focus on writing the API logic and use tools that allow them to automatically create documentation and specifications based on that logic. In general, both approaches, Code First and Contract First, can be combined within the same API development project. In this case, Code First is used for rapid prototyping, followed by Contract First to formalize the contract. I hope this article is helpful for you in preparation for a job interview or in refreshing your knowledge about REST API.
