API Development Methods Flashcards

Question 1

What is an application programming interface, in general terms?

Accepted Answer

An application programming interface is a defined set of rules and operations that lets one software component request services or data from another without knowing its internal workings. It describes which requests are allowed, what inputs they accept, and what responses they return. Programs depending on it treat this description as a contract.

Question 2

What does the term endpoint mean in API design?

Accepted Answer

An endpoint is a specific address, usually a uniform resource locator path, where a client sends a request to reach one particular resource or operation. Each endpoint combines a location with an action, such as retrieving a list of orders or creating a new customer record. A single API exposes many endpoints.

Question 3

What is a resource in the context of a web API?

Accepted Answer

A resource is any piece of information or concept that an API exposes, such as a user, an invoice, or a product catalog entry. Resources are usually named with nouns rather than verbs, so the path describes what the thing is. Each resource has a unique identifier.

Question 4

Why is a stateless design considered important for scalable APIs?

Accepted Answer

A stateless design means the server does not store session context between requests, so every request must carry all the information needed to process it. This makes it easier to spread traffic across many servers, since any server can handle any request. Clients may therefore send more data per call.

Question 5

What roles do the client and server play in an API exchange?

Accepted Answer

The client is the program that sends a request asking for data or an action, such as a mobile app or a web browser. The server is the program that receives that request, performs the work, and sends back a response. Clients initiate exchanges, and servers wait to respond.

Question 6

Why is JSON widely used as a data format for web APIs?

Accepted Answer

JSON, which stands for JavaScript Object Notation, is a lightweight text format that represents data as key and value pairs, arrays, and nested objects. It is easy for people to read and simple for programs in most languages to parse. Because it is compact and widely supported, it has become a common default.

Question 7

How do public APIs differ from private APIs?

Accepted Answer

Public APIs are open to external developers, usually with published documentation and minimal restrictions beyond authentication and usage limits. Private APIs are restricted to internal teams within one organization, where they support internal systems and services. Partner APIs sit between the two, shared only with selected business collaborators.

Question 8

What is a software development kit in relation to an API?

Accepted Answer

A software development kit is a bundle of libraries, sample code, and tools that helps developers use an API in a specific programming language. It hides some low level details of making requests. Using one can speed up integration, but developers should still understand the underlying endpoints.

Question 9

What does REST stand for and what kind of style does it describe?

Accepted Answer

REST stands for Representational State Transfer, an architectural style for distributed systems defined by a set of constraints. Its core idea is that clients interact with resources through a uniform interface, using standard operations and representations. Systems that follow these constraints are called RESTful.

Question 10

What are the constraints that a system must satisfy to be considered RESTful?

Accepted Answer

The commonly taught constraints are client and server separation, statelessness, cacheability, a layered system, a uniform interface, and optional code on demand. Together they keep components loosely coupled and predictable. Code on demand is optional and used rarely, since it lets servers send executable code to clients.

Question 11

What does it mean for a REST interface to be uniform?

Accepted Answer

A uniform interface means that all resources are accessed through a consistent set of rules, regardless of their type. Clients use standard HTTP methods, identify resources with uniform resource identifiers, and manipulate them through representations such as JSON. Because every resource follows the same pattern, developers can learn it faster.

Question 12

Why should REST APIs use nouns in paths instead of verbs?

Accepted Answer

Paths should name resources, because the HTTP method already expresses the action. For example, a path such as /orders identifies a collection, and a request using the POST method creates a new order in it. Putting verbs such as create or delete in paths duplicates information and makes the API harder to learn.

Question 13

How are resource identifiers typically structured in a REST URI?

Accepted Answer

A typical REST URI contains a base address, a collection name, and an identifier for a specific item, such as https://api.example.com/books/42. Collection names are usually plural, so the path reads naturally for both lists and single items. Query parameters can add filters, sorting, or paging without changing the resource being addressed.

Question 14

What does HATEOAS mean and how does it relate to hypermedia?

Accepted Answer

HATEOAS stands for Hypermedia As The Engine Of Application State. It means that a response includes links that tell the client which actions are available next, so clients can navigate the API without hardcoding every URL. Many REST APIs skip this constraint in practice, yet it remains part of the formal definition.

Question 15

What is the difference between a resource and its representation?

Accepted Answer

A resource is the conceptual thing being managed, such as a customer account, while a representation is a particular format of its current state, such as a JSON document. One resource can have several representations, for example a summary and a detailed view. Clients exchange representations, not the internal storage of the resource.

Question 16

Why should API resources be designed around business concepts rather than database tables?

Accepted Answer

Resources modeled on business concepts give clients a stable, meaningful interface that stays the same even when the storage design changes. Exposing tables directly couples clients to internal details, so a schema change can break many integrations. Designing around customers, orders, and invoices also makes the API easier for newcomers to understand.

Question 17

What is the purpose of the GET method in HTTP?

Accepted Answer

The GET method asks the server to retrieve a representation of the specified resource without changing it. Requests using GET should be safe, meaning they have no intended side effects on server state. Browsers and caches rely on this property, so GET is the usual choice for reading data.

Question 18

Which HTTP methods are commonly used to create, replace, and delete resources?

Accepted Answer

POST is commonly used to create a new resource under a collection, PUT to replace a resource at a known address, and DELETE to remove it. PATCH is often used for partial updates that change only some fields. Each method has an expected meaning, so choosing the right one makes the API predictable.

Question 19

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

Accepted Answer

An idempotent method produces the same effect on the server whether it is sent once or repeated many times. GET, PUT, and DELETE are idempotent, while POST is not, because repeating a POST can create duplicate records. This property helps clients safely retry requests after a network timeout.

Question 20

What do HTTP status codes in the 2xx range indicate?

Accepted Answer

Status codes in the 2xx range indicate success, meaning the server received, understood, and accepted the request. The code 200 means OK and is common for successful reads, while 201 means a new resource was created. The 204 code indicates success with no response body, often used after a deletion.

Question 21

What is the difference between a 400 and a 404 status code?

Accepted Answer

A 400 status code means the server could not process the request because the client sent malformed or invalid data, such as a missing required field. A 404 status code means the server cannot find the resource at the requested address. The first points to bad request content, the second to a missing resource.

Question 22

What kinds of information do request headers carry besides the URL?

Accepted Answer

Request headers carry metadata about the request, such as the format the client accepts, the type of body being sent, and credentials like an authorization token. Headers are name and value pairs. Because they are separate from the path, they keep the address clean while still giving context.

Question 23

Why is it important that a 500 status code is not used for client mistakes?

Accepted Answer

A 500 status code signals an unexpected failure on the server side, so using it for client mistakes misleads developers about where the problem lies. Clients may retry a 500 response when the real issue is a malformed request. Accurate codes let consumers decide whether to fix their input or wait and try again.

Question 24

What is the purpose of a query string in a request URL?

Accepted Answer

A query string follows a question mark in the URL and passes optional parameters, such as filters, sort orders, or page numbers. Each parameter is written as a name and value pair, with multiple pairs separated by ampersands. The server uses these values to shape the response without changing which resource is addressed.

Question 25

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

Accepted Answer

Authentication verifies who the client is, usually by checking credentials such as a password, key, or token. Authorization decides what that verified client is allowed to do, such as reading one dataset but not deleting it. A request can pass authentication and still fail authorization, which is why both checks matter.

Question 26

How does an API key differ from an OAuth access token?

Accepted Answer

An API key is a long secret string that identifies a calling application, and it is often sent in a header with each request. An OAuth access token is issued after permission is granted, usually with a limited lifetime and defined scopes. Tokens generally offer finer control for acting on behalf of a user.

Question 27

Why should API keys never be placed in publicly downloadable app code?

Accepted Answer

Anything shipped to a user's device, such as a web page script or a mobile app bundle, can be inspected, so a secret key placed there can be copied and misused. Anyone holding the key can make requests as your application. Sensitive calls should go through a backend server that holds the secret.

Question 28

What is a bearer token, and how is it normally sent?

Accepted Answer

A bearer token is a credential that grants access to whoever presents it, so it does not need further proof of identity beyond possession. It is normally sent in the Authorization header using the word Bearer followed by the token value. Bearer tokens must therefore travel only over encrypted connections.

Question 29

What is the purpose of rate limiting in a public API?

Accepted Answer

Rate limiting caps how many requests a client can make within a set time window, protecting the service from overload and from abusive usage. When a client exceeds the limit, the server typically returns a 429 status code, often with information about when to retry. Limits help providers allocate capacity fairly across many consumers.

Question 30

What are the main ways to version a web API?

Accepted Answer

Common approaches include putting a version number in the URL path such as /v1/orders, sending a version in a custom request header, adding a query parameter, or using a versioned media type in the Accept header. Each option has compromises in visibility and caching. Teams should pick one approach and apply it consistently.

Question 31

What is a breaking change in API versioning?

Accepted Answer

A breaking change is any modification that forces existing clients to change their code to keep working, such as removing a field, renaming an endpoint, or changing a required parameter. Adding an optional field is usually safe because existing clients can ignore it. Breaking changes usually require a new version.

Question 32

Why is it wise to deprecate an API version before removing it?

Accepted Answer

Deprecation gives existing consumers advance notice and time to migrate, so the removal does not cause unexpected outages. Deprecated versions usually keep working for a stated period while documentation and responses signal the coming change. Clear communication about timelines builds trust with the developers who depend on the API.

Question 33

What is an OpenAPI specification and what is it used for?

Accepted Answer

An OpenAPI specification is a machine readable description of an API, written in YAML or JSON, that lists endpoints, methods, parameters, and response shapes. Tools can read it to generate documentation, client libraries, server stubs, and tests. Because the description lives alongside the code, it helps keep documentation and implementation in agreement.

Question 34

What is contract testing, and how does it help API teams?

Accepted Answer

Contract testing checks that a provider and its consumers agree on the shape and behavior of messages exchanged between them. Each side verifies its assumptions against a shared definition, so a change that breaks a consumer is caught before deployment. This approach reduces the need for slow, full environment runs.

Question 35

What advantage do black box API tests have over unit tests?

Accepted Answer

Black box API tests send real requests and check only the observable responses, without relying on internal code. This means they confirm that the deployed interface behaves as clients expect, including routing, serialization, and status codes. Unit tests remain valuable for logic, but black box tests catch integration problems that unit tests can miss.

Question 36

What should a good API error response include?

Accepted Answer

A good error response includes a correct status code, a machine readable error identifier, and a human readable message that explains what went wrong. It may also name the offending field and suggest how to fix the problem. Consistent formats let clients handle failures in one place.

Question 37

What is the purpose of an interactive API documentation page?

Accepted Answer

An interactive documentation page lets developers browse endpoints and send sample requests directly from the browser, seeing live responses. This shortens the time needed to understand an API, because readers can test ideas without writing code first. Good pages also show example requests, sample responses, and descriptions of every parameter.

Question 38

What is a mock server, and when would a team use one?

Accepted Answer

A mock server is a substitute that responds to API requests with predefined example data, following the published specification. Teams use one when the real backend is not ready, when a dependency is costly or unavailable, or when a frontend needs to be built in parallel. Mock responses let development continue before the real service exists.

Question 39

How does generating documentation from a shared specification reduce outdated information?

Accepted Answer

When documentation is produced from the same specification that drives validation and code generation, it is updated whenever the specification changes. Manually written pages, by contrast, tend to fall behind as endpoints evolve. Automatic generation therefore keeps readers working from the current behavior of the API.

Question 40

What does a load test measure for an API?

Accepted Answer

A load test measures how an API performs under expected or heavy traffic, examining response times, throughput, and error rates. It helps teams find bottlenecks and estimate how many requests the system can handle before performance degrades. Such tests are usually run in a staging environment that resembles production.

API Development Methods Flashcards

1Core API Concepts

2REST Design Principles

3HTTP Methods and Responses

4Authentication, Versioning, and Limits

5Documentation and Testing Practices

Learning Resources