12 Best Web Or Rest API Interview Questions Answers - Algrim.co

12 Best Web Or Rest API Interview Questions Answers - Algrim.co Looking to get as prepared as you can for your upcoming technical interview? We have the absolute best API interview questions and answers to help you do just that. In our guide, we're going to cover what interview questions you might want to prepare for and how you might consider answering them to the hiring manager or HR representative that you are speaking with. Why should you study for API interview questions? APIs, or Application Programming Interfaces, are at the very center of all types of software development. Whether you are a web developer working at a small agency, or even working in technical leadership at a bleeding-edge organization like NASA, understanding APIs, their different forms, and their purposes is essential to growing in your software development career. For this reason, most technical interviews will cover at least some aspect of API design and usage. These questions have been put together to assess a candidate’s understanding of the different types of APIs they may encounter, how to use them, and what their purposes are for from a practical standpoint. Web or Rest API interview questions & answers 1. Describe what an API is and what it is used for, in a practical sense. API stands for Application Programming Interface. Depending on the type of application a developer is dealing with, an API might be defined by a list of URLs or by a list of methodNames() which are available to be called from some software module. There are other ways that an API might be defined, but these are two of the most common ways for defining APIs a developer would work with. An API which is defined by a list of URLs is typically called a web service. You may also hear this type of API described as a RESTful web service, which is a web service API which has some additional important properties. In essence, a web service API is a map between a URL you can access over the internet (e.g. https://www.an-api-example.com/users), and some business logic that will execute within a software module. In the case of the example URL we used above, https://www.an-api-example.com/users, it is likely that this URL would map to some business logic which retrieves a list of users from a database, and returns the list to the person who accessed the URL. If a developer needs a list of users, he can access such a URL and then use the result to render them inside is the application’s user interface. 2. What is an API for a software module, like a Java Class or a Common.js module for example, how is it different than a web-service API? In the case of an API defined by methodNames() in a Java Class or Common.js module, we are discussing an element of software called a module. A software module is some self-contained piece of code that we can “import” into other parts of our application. In a node.js or javascript application the following syntax might be familiar for importing: // two different ways of importing software modules in React import List from ‘list’; const List = require(‘list’); In a Java application the following would look more familiar: import java.util.List After importing our List module, we now have access to a set of methodNames() which are exposed in our list, and we can use them in our own code. For example, we may be able to execute methods like: List.iterate() List.previousElement() List.nextElement() List.empty() List.push() List.pop() List.shift() These method names are the API of the “List” software module. A user can invoke these methods to perform various operations on any List they use within their application. 3. Think of a real-world analogy for an API. How would the flight controls on an airplane’s flight deck be analogous to an API? Although on an aircraft’s flight deck we are usually imagining buttons and switches, these flight controls on an airplane’s flight deck are similar to the APIs we think of in software, because they are simplified interfaces into the complicated inner workings of the aircraft. When an airplane pilot sees his cockpit dashboard, he as an array of buttons in front of him. In a simplified example, he might have 3 primary inputs. 1) A yoke that he can move left, right, up, or down to change the direction of the plane. 2) A button to engage an auto-pilot system. And 3) a system for increasing or decreasing engine power. Whether a pilot uses button 1, 2, or 3, the cascade of events which occur throughout the aircraft is sophisticated and too advanced for most pilots or engineers to be interested in understanding. For example if the 1) Yoke is moved to the left, hydraulic fluid is sent through the aircraft's systems, flaps on the wings and rudders work in synchrony in order to control the direction of the plane, and automated computer systems monitor progress of the action adding in autocorrections and safety alerts in the case of improper usage of the Yoke; the pilot does not have to control these numerous processes manually. Instead, he simply has moved the yoke to the left, and his plane has turned left safely. The yoke provides a simple interface (an API) into the vastly more complicated inner workings of the plane. The end result is “Pilot turns wheel left -> plane engages in a cascading number of actions and then goes left”. This is similar to a web service API or a software modules’ API because a similar goal is shared. A developer (or pilot, in our example), can interact with a vastly sophisticated system by only needing to learn a smaller set of abstracted URLs, methodNames(), or “buttons” available to them. 4. What is one great resource you use to learn about an API as you begin using it? Documentation is key to understanding the usage of an API, and should often be the first place you look to understand the types of API methods available and the sorts of messages or actions you can expect after interacting with those methods. 5. If you have found incomplete or inaccurate API documentation, what are some other options for being productive with the API? Unfortunately, since we live in a world of priorities, full API documentation may not be available for the API you are using. Or, it might have outdated information which proves more confusing than useful. In this case, online communities like StackOverflow often have community-provided answers to the problems that trouble you. Finally, if answers are not available through documentation or the community it is sometimes possible to take a closer look yourself at the API’s codebase to see the methodNames() available for you to call. This is an unfortunate scenario, but perhaps also an opportunity to improve the documentation of a software module! 6. What is a RESTful API? Describe some of its properties. A RESTful API is a type of web service API which has additional properties for it to conform to the formal REST specification. First, a RESTful API should be stateless. This means that the server running the API has no information about the interacting user’s state. In a practical sense, this means that every request to the API must have all the information necessary to fulfill the request, and also that a response given by a stateless API will never depend on information it has held onto from a previous request. A RESTful API should also provide in its responses a reference to where the user can find the next set of resources. For example, if I interact with an API to return me a paginated list of users, a RESTful API will contain in its response both the paginated list of users, as well as the URL from which I can retrieve the next page of users. 7. What are some tools in Node.js that can help you write an API? There are a number of tools called Web Application Frameworks in Node.js that can help to write APIs efficiently. Most of these tools, in general, offer convenience methods for mapping URL traffic to function calls in your application, and for formulating consistent responses. Some of these tools include express.js, koa.js, and koa2.js. There are dozens more, and a search for Node.js Web Application Framework will yield many results for which you can analyze the pros and cons which apply to your project’s needs. 8. According to the HTTP specification, what is the proper response from a web service API when an API request was successful? A successful response from an API web service should read status: 200. 9. According to the HTTP specification, what is the proper response from a web service API when an API request caused an exception within the application and was not successful? A response from an API web service which has suffered an exception and failed should read status: 500. 10. According to the HTTP specification, what is the proper response from a web service API when the given URL cannot be found? A response from an API where the given URL could not be found should be status: 400. 11. In building a web service API, some of its functionality might need to be restricted. What is an example of when you would need to restrict part of a web service API and how? A web service API might need to be restricted for users who have already been logged into the system, for example. Imagine an API for a chat app which requires users to login, Bob cannot access an API response for a Jeffiner’s private message content, because he is not logged into Jennifer’s account. There are a number of ways to accomplish this security, one of which is with the exchange of tokens. When Bob logs into his account at the chat app, after verifying that his username and password are correct, Bob will be issued a token. Once given this token, every time he makes a message in the Chat app, his message can carry this token, and the API can re-verify Bob without needing him to re-enter his username and password. Since Jennifer and Bob do not share one another’s tokens, they are unable to see each other’s content. 11. Look at the following two API URLs. How would you likely infer that they differ? https://my-api.com/api/user/19XDDVVND98DFE and https://my-api.com/api/users? It looks as if the first API URL returns the data for a particular user, while the second API URL returns a list of users. The reason this inference can be made is that typical web service API specifications say that in order to retrieve on an instance of a resource, the URL pattern should include the resource-name followed by the resource-id. In our first URL example, we see that the resource “user” is being followed by an ID we can reasonably assume is a “userID”. The typical specification for a web service URL also says that a list of resources is accessed by its resource-name without any ID to follow. We can see in our second URL example, the resource “users” is defined the URL without any ID to follow. This implies we will receive a list of users in response. Beware that this is not always the case for all APIs you might encounter. Because APIs are human-build pieces of machinery, they often have nuances and quirks which make them differ slightly from expected specifications. For example, some small APIs you encounter might have reversed resource-names and resource-ids in their URLs. This can be confusing! However, it can be an opportunity to discuss with your team, contribute to the project, and improve its specifications. 12. How can a developer test a web service API? Tools called REST clients are an excellent way for a developer to test a web service API. Examples of these tools are Postman or Advanced REST Client. As mentioned earlier, a web service API is typically defined as a list of URLs that a developer can interact with to trigger some behavior in the software. Within a REST client, a developer can define and save this full list of API URLs, and then easily send sample requests to the API to test its functionality as the API is developed. Or simply to experiment and better understand its workings. This can be especially useful in the case that the primary purpose of the web service API is to power a user interface. A REST client removes a dependency between the user interface developers and the API developers, because both teams can test the API before the user interface has finished development.