Questions about good REST API design are part of almost every job interview you will ever have as a back end or full stack developer. It's important to understand the core concepts of REST and how to apply them when designing APIs for real-life use cases. To freshen up your memory and help you prepare for your next job interview, I have collected the most common API design interview questions that I have come across in my career:
Question 1: What is a RESTful API?
A RESTful API is an application program interface (API) that is based on representational state transfer (REST), an architectural style for designing web services. In REST, standard HTTP methods are used for creating, reading, updating and deleting resources.
Question 2: What is a resource in REST?
A resource can be any piece of information that can be named, e.g. a document, an image or a function. In REST, each resource is uniquely addressed by a Uniform Resource Identifier (URI).
Resources can be singletons (e.g. {% c-line %}/customers/:customerId{% c-line-end %}) or collections (e.g. {% c-line %}/customers{% c-line-end %}). Any resource can again hold sub-collection of resources (e.g. {% c-line %}/customers/:customerId/accounts{% c-line-end %}).
Question 3: What are the architectural constraints of REST?
Client-server architecture: The user interface is separated from data storage which enables easier portability of the user interface across platforms and simplifies scaling server components.
Statelessness: No client context is being stored on the server between requests. Each client request holds all necessary information for the server to fulfill the request, including session state.
Cacheability: Server responses are marked as either cacheable or non-cacheable. Cacheable responses can reduce server-client communication for further similar requests.
Uniform interface: The four constraints for uniform interfaces are:
- Resource identification in requests: Individual resources are identified in requests, e.g. through URIs. Resource representations returned from the server (e.g. JSON, XML) are independent from the internal representation (e.g. database entry).
- Resource manipulation through representations: With the representation of a resource, the client has enough information to update or delete a resource.
- Self-descriptive messages: Each response holds enough information for a client to know how to process it (e.g. through media type headers).
- Hypermedia as the engine of application state (HATEOAS): After accessing an initial URI, clients should be able to use server-provided links to discover all other available resources it needs.
Layered system: REST APIs can be composed of hierarchical components, no component can see beyond the other component that it immediately interacts with.
Code-on-demand (optional): Servers can temporarily customize the functionality of a client by transferring executable code.