RESTful API Development Flashcards

Question 1

What does REST stand for, and what kind of architectural style is it?

Accepted Answer

REST stands for Representational State Transfer. It is an architectural style for distributed systems, defined as a set of constraints that web services can follow to be scalable, simple, and interoperable. It describes how clients and servers exchange representations of resources over a network, usually using HTTP.

Question 2

What is the client-server constraint in REST, and why does it help?

Accepted Answer

The client-server constraint separates the user interface concerns of the client from the data storage and processing concerns of the server. This separation lets each side evolve independently, so a mobile app and a web app can both use the same server. It also improves scalability.

Question 3

What does it mean for REST to be stateless, and what is the benefit?

Accepted Answer

A stateless REST API means that each request from a client contains all the information the server needs to process it. The server does not store client session context between requests. The main benefit is simpler scaling, because any server instance can handle any request, and failures are easier to recover from.

Question 4

What is a uniform interface, and why is it central to REST?

Accepted Answer

A uniform interface means that components interact through a standard, consistent set of conventions rather than custom protocols for each service. In REST this includes identifying resources with URIs, manipulating them through their representations, using self-descriptive messages, and following hypermedia links. Uniformity lets clients and intermediaries work with many different APIs consistently.

Question 5

What is a resource in REST, and how does it differ from a database table?

Accepted Answer

A resource is any named concept that an API exposes, such as a customer, an order, or a collection of invoices. A resource is not the same as a database table, because it is an abstraction that clients interact with, and it may combine data from several tables or come from an external service.

Question 6

What is a representation, and how do clients usually request a specific format?

Accepted Answer

A representation is a snapshot of a resource's state in a particular format, such as JSON or XML. Clients usually request a format through the Accept header, listing the media types they can understand. The server then responds with a Content-Type header that identifies the format it actually returned.

Question 7

What is the cacheable constraint, and which responses should be cacheable?

Accepted Answer

The cacheable constraint requires responses to label themselves as cacheable or non-cacheable, so clients and intermediaries know whether they may reuse the data. Responses to safe requests that return data that changes slowly are good candidates. Caching reduces latency and server load, but stale data must be handled carefully.

Question 8

Why is the layered system constraint useful in a REST architecture?

Accepted Answer

The layered system constraint lets an architecture be composed of hierarchical layers, where each component sees only the layer it directly interacts with. Load balancers, proxies, and gateways can sit between client and server without the client knowing. This supports security policies, load distribution, and shared caching, all without changing either endpoint.

Question 9

What is a Uniform Resource Identifier, and how does it relate to REST?

Accepted Answer

A Uniform Resource Identifier is a string that names a resource, such as a path in a web address. In REST, every resource is addressed through a URI, so the URI acts as the stable name clients use to find and act on that resource. Good design keeps it predictable.

Question 10

Should REST URIs use nouns or verbs to name resources, and why?

Accepted Answer

REST URIs should generally use nouns that name resources, such as /orders or /orders/42, rather than verbs that describe actions. The HTTP method already expresses the action, so a request to delete an order uses DELETE on the order's URI instead of a path like /deleteOrder. Nouns keep the interface consistent.

Question 11

What is a collection resource, and how does it differ from a single item resource?

Accepted Answer

A collection resource represents a group of similar items, usually addressed with a plural noun such as /books. A single item resource represents one member of that collection, addressed by an identifier such as /books/7. Clients list or create items through the collection and read, update, or delete individual items through the item URI.

Question 12

Why should URIs be hierarchical, and what does a nested path express?

Accepted Answer

Hierarchical URIs express containment or ownership, so a path such as /customers/15/orders shows that the orders belong to customer 15. The structure helps humans read the API and lets clients navigate from parent resources to related children. Nesting should stay shallow to keep URIs readable.

Question 13

What is a query parameter, and what is it commonly used for in REST APIs?

Accepted Answer

A query parameter is a name and value pair appended to a URI after a question mark, such as ?status=open. In REST APIs, query parameters commonly filter, sort, search, or paginate a collection without changing the resource being identified. They let one base URI serve many views.

Question 14

What does it mean for a URI to be stable, and why does stability matter?

Accepted Answer

A stable URI keeps the same address for the same resource over time, even when its internal storage or implementation changes. Stability matters because clients, bookmarks, and other systems store these addresses, and breaking them forces every consumer to update. Designers avoid exposing volatile internal details in public paths.

Question 15

How should an API handle a resource whose URI has changed permanently?

Accepted Answer

The API should respond with the 301 status code, Moved Permanently, and include a Location header that gives the new URI. This tells clients and search engines to use the new address from now on. Keeping the old URI redirecting for a while gives existing clients time to migrate.

Question 16

What is content negotiation, and how does it relate to a single URI?

Accepted Answer

Content negotiation is the process by which a server chooses the best representation of a resource for a client, based on request headers such as Accept and Accept-Language. The same URI can return JSON to one client and XML to another. One identifier can serve several formats.

Question 17

What are the main HTTP methods used in RESTful API design?

Accepted Answer

The main HTTP methods are GET, POST, PUT, PATCH, and DELETE. GET reads a resource, POST creates a resource or triggers processing, PUT replaces a resource, PATCH partially updates it, and DELETE removes it. Each method has a defined meaning that clients and servers share.

Question 18

What does it mean for an HTTP method to be safe, and which methods are safe?

Accepted Answer

A safe method is one that is meant to be read-only, so it should not change server state from the client's point of view. GET and HEAD are safe, while POST, PUT, PATCH, and DELETE are not. Safety lets caches, crawlers, and retry logic call these methods without causing unintended side effects.

Question 19

What does it mean for an HTTP method to be idempotent, with an example?

Accepted Answer

An idempotent method produces the same server state whether it is sent once or many times with the same request. For example, repeating PUT on /users/5 leaves the same final state. GET, PUT, and DELETE are idempotent, and POST is not.

Question 20

What does the 201 Created status code signal, and what should the response include?

Accepted Answer

The 201 Created status code signals that a request succeeded and produced a new resource. The response should include a Location header containing the URI of the new resource, and it often includes the created representation in the body. This tells the client exactly where to find what it just made.

Question 21

When should an API return 404 Not Found instead of 403 Forbidden?

Accepted Answer

An API should return 404 Not Found when the resource does not exist, or when it wants to hide the existence of a resource from a client who is not allowed to see it. It should return 403 Forbidden when the client is recognized and authenticated but lacks permission for the action.

Question 22

What is the difference between 401 Unauthorized and 403 Forbidden?

Accepted Answer

A 401 Unauthorized response means the request lacks valid authentication credentials, so the client must authenticate first. A 403 Forbidden response means the server understood the request and the client is identified, but the client is not permitted to perform the action. Retrying with the same credentials will not help with a 403.

Question 23

What does the 409 Conflict status code indicate, and when is it used?

Accepted Answer

The 409 Conflict status code indicates that the request could not be completed because it conflicts with the current state of the target resource. A common case is an update that was based on an outdated version of the resource, or an attempt to create a record with a unique key that already exists.

Question 24

Why should a 500 Internal Server Error response not expose stack traces to clients?

Accepted Answer

Stack traces should stay out of public responses because they can reveal internal file paths and library versions. A 500 response should instead return a generic error message and a correlation identifier that the team can match against server logs. Detailed diagnostics belong in logs, not in public responses.

Question 25

What are the main parts of an HTTP request that a REST API reads?

Accepted Answer

An HTTP request contains a method, a target URI, headers, and an optional body. The method states the action, the URI identifies the resource, headers carry metadata such as content type, authentication, and accepted formats, and the body carries data for methods like POST or PUT.

Question 26

What is the purpose of the Content-Type header in a request?

Accepted Answer

The Content-Type header tells the server the media type of the body being sent, such as application/json. Without it, the server may not know how to parse the data. APIs typically reject requests with a missing or unsupported content type using a 415 Unsupported Media Type response.

Question 27

How should an API validate incoming JSON request bodies?

Accepted Answer

An API should check the body against a defined schema, verifying required fields, data types, value ranges, and allowed formats before performing any action. Invalid input should be rejected with a 400 Bad Request or 422 response that names each problem. Validation at the boundary protects the rest of the system from malformed data.

Question 28

What is pagination, and why do large collection responses need it?

Accepted Answer

Pagination divides a large collection into smaller pages, so the server returns one manageable slice per request. Without it, a single response could be very large, slow to produce, and expensive for clients to parse. Clients usually move between pages using query parameters or links provided in the response.

Question 29

What does a hypermedia link in a REST response provide to the client?

Accepted Answer

A hypermedia link gives the client a URI for a related action or resource, so the client can discover next steps without hardcoding every address. For example, an order response might include a link to cancel the order or to view the customer. This is often called HATEOAS.

Question 30

What is the difference between a partial update with PATCH and a full replacement with PUT?

Accepted Answer

PUT sends a complete representation of a resource and replaces the stored version with it, so omitted fields are generally cleared or reset. PATCH sends only the changes the client wants to apply, leaving other fields untouched. Choosing the right method keeps requests smaller and avoids accidentally erasing data.

Question 31

Why should list responses include metadata such as total counts or next links?

Accepted Answer

Metadata helps clients know how much data exists and how to retrieve the rest of it without guessing. A total count supports progress indicators and paging controls, while next links let clients follow the sequence safely even when the underlying data changes. Including metadata keeps the client logic simple and predictable.

Question 32

How should an API respond to a successful DELETE request?

Accepted Answer

A successful DELETE should return 204 No Content when the removal is complete and there is nothing useful to return in the body. Some APIs instead return 200 OK with a representation of the deleted resource or a confirmation message, depending on team conventions. Either way, the response should be consistent across the API.

Question 33

Why do APIs need versioning, and what are two common ways to version them?

Accepted Answer

Versioning lets an API change in ways that could break existing clients without forcing every consumer to update at once. Two common approaches are placing the version in the URI, such as /v1/orders, and sending it in a request header or media type. Either approach should be applied consistently across the API.

Question 34

What is a backward compatible change to a REST API?

Accepted Answer

A backward compatible change is one that existing clients can keep using without modification. Examples include adding a new optional field to a response or a new endpoint, since clients that ignore unknown fields continue to work. Removing a field, renaming it, or changing its meaning is usually a breaking change.

Question 35

What structure should a consistent JSON error response have?

Accepted Answer

A consistent error response usually includes a machine-readable error code, a human-readable message, and sometimes a list of field-level details. It should use the same shape for every error, so clients can parse failures with one routine. The HTTP status code still carries the general category of the failure.

Question 36

What is the difference between authentication and authorization in an API?

Accepted Answer

Authentication verifies who the caller is, usually by checking credentials or a token. Authorization decides whether that verified caller is allowed to perform a specific action on a specific resource. A request can pass authentication and still fail authorization, which is why APIs should check both on every protected endpoint.

Question 37

How does a bearer token work in a REST API request?

Accepted Answer

A bearer token is sent in the Authorization header using the form Bearer followed by the token value. The server validates the token on each request and then identifies the caller. Because anyone holding the token can use it, tokens must be sent only over HTTPS and kept secret.

Question 38

Why must REST APIs use HTTPS when transmitting credentials?

Accepted Answer

HTTPS encrypts the connection between client and server, so credentials and tokens cannot be read by anyone observing network traffic. Without encryption, a password or bearer token sent in a header could be captured and reused by an attacker. Transport security is a baseline requirement, not an optional extra.

Question 39

What is OpenAPI, and why do teams use it to document REST APIs?

Accepted Answer

OpenAPI is a widely used specification format for describing REST APIs in a machine-readable document, covering endpoints, methods, parameters, request bodies, and responses. Teams use it to generate interactive documentation, client libraries, and tests from one shared source. Keeping the description and the implementation aligned reduces misunderstandings between frontend and backend developers.

Question 40

What is rate limiting, and how should an API tell a client it has been throttled?

Accepted Answer

Rate limiting caps how many requests a client can make within a time window, protecting the service from overload and abuse. When a client exceeds the limit, the API should respond with 429 Too Many Requests and may include a Retry-After header that says when to try again. Clients should wait before retrying.

RESTful API Development Flashcards

1Core REST Principles

2Resources and URI Design

3HTTP Methods and Status Codes

4Request and Response Design

5Versioning, Errors, and Security

Learning Resources