02-AREAS

A promise of REST APIs is good decoupling of clients and services. This is achieved in part by reducing business logic as much as possible in the client application. For example, a client application may use a form for collecting information used in a POST operation to create an API resource, or to edit an existing resource before updating it with a PUT or PATCH operations. The client then maps the form fields to the properties of the operation’s request body. Clients can use front end frameworks and libraries to perform lots of low-level validation in the front end corresponding to JSON schema constraints

Forms which use required data fields for properties that are required in the JSON schema using date pickers checkboxes for selecting Boolean true or false values drop down lists that allows selection from a list of fixed enum values constrained numeric text entry form fields that enforce a regular expression from a pattern constraint

However, this only covers “syntactic” or static field-level validation. Often, an API will also have business rules that the client must follow. Secure API services will enforce those business rules in the API operations

Parse the options and (JSON) request body and return a 400 Bad Request if any of the request data is malformed (i.e. does not satisfy the constraints of the operation (such as required body or required parameters) or all the JSON Schemas associated with the operation’s parameters or request body) Verify that the caller passes valid Authorization to the API call, and return 401 Unauthorized if not Verify that the caller is authorized to perform the API operation, and return a 403 Forbidden error if not. Verify the state of the application and return 409 Conflict if the operation would put the application into an inconsistent state Verify the semantics of the request body and return a 422 Unprocessable Content error if the request is incomplete, inconsistent, or otherwise invalid

One way to implement a dry run is to create a separate "validation” operation for each API operation. This has the significant disadvantage of greatly increasing the footprint (size) of the API and adding a lot of duplication.

Rather than duplicate operations to add sibling validation operations, another approach is to add a ?dryRun=true query parameter to the operations. When used, the operation can return 204 No Content if the request contains no problems. The dryRun parameter acts as a “short circuit” in the API operation. The implementation performs the full validation it would normally do before executing the desired behavior, but then stops before actually executing anything other than the validation.

This pattern has a small impact on the API footprint compared to making sibling validation operations. A smaller footprint makes the API easier to read and understand. It is also a good use of the DRY principal, since you do not have to duplicate the definition of all the operation request parameters and request bodies, which opens up the chance for them to become out of sync.

Deeply nested schemas can become unwieldy and hard to maintain. For instance, a User object containing an Address object, which in turn contains a Location object, can quickly become complex. Why it matters: Simplifying schemas enhances readability and maintainability, making it easier for both developers and consumers to understand and work with the API.

Defining schemas, parameters, and responses inline repeatedly instead of using the components section leads to redundancy and potential inconsistencies. Why it matters: Leveraging components promotes reusability and consistency across the API specification.

Logically group your APIs into smaller, domain-specific specs — like auth.yaml, payment.yaml, orders.yaml. Use tags in OpenAPI to group related endpoints (like Order, Customer, Admin) even within a single file if needed.

/openapi ├── auth.yaml ├── customer.yaml ├── orders.yaml └── components/ └── common-schemas.yaml

Start with Real-World Examples: Show complete request/response cycles, including auth headers and errors. For example, show what a GET /users call returns in JSON.

Modern Tools​ Redocly: Offers Redoc for API docs plus additional tools like Revel for flexible branding without rigid templates, Reef for API monitoring, and an API registry to manage multiple OpenAPI definitions. Theneo: Uses AI to generate API references automatically, cutting down manual work. Started with docs but now expands its AI tools to streamline the whole API development process. Stoplight: Helps with API design and governance through tools like Stoplight Studio (visual OpenAPI editor), Prism (open-source HTTP mock server), and Spectral (linting tool to enforce API standards). Works best for teams taking a design-first approach. Postman: Goes beyond basic docs by providing workspaces, automated testing, monitoring, and governance. Connects deeply with GitHub, GitLab, and CI/CD pipelines as a complete API lifecycle tool. SwaggerHub: Lets teams collaborate on APIs using OpenAPI or AsyncAPI specs while managing them throughout their lifecycle. Built by the same team behind Swagger. Zuplo: Runs as a lightweight, fully-managed API platform built for developers, featuring GitOps, quick deployment, and unlimited preview environments. Works for both hobbyists and engineering leaders implementing auth systems. Gravitee.io: Works as an open-source API management platform with a full ecosystem including API Gateway, Management, Access Management, and observability tools. APIdog: Simplifies creating, managing, and testing APIs for both developers and testers. Focuses on building reliable, secure, and fast APIs. ReadMe: Helps companies create, manage, and publish API docs through a user-friendly interface that makes documentation accessible to users. dapperdox.io: Generates and serves open-source API docs for OpenAPI Swagger specs. Combines specs with docs, guides, and diagrams using GitHub Flavored Markdown. Docusaurus: Built by Meta as an open-source documentation platform. Lets developers write in Markdown or MDX and, being React-based, allows extensive customization. Scalar: Turns OpenAPI specs into interactive docs with an integrated API playground for testing endpoints directly in the documentation.

Example of an Actionable API Error Message​ { "status_code": 400, "error": "Bad Request", "message": "The 'email' field is missing or invalid.", "suggestion": "Please provide a valid email address in the format 'user@example.com'.", "error_code": "VALIDATION_FAILED_001", "trace_id": "xyz1234abcd" } This message clearly identifies: The nature of the error (400 Bad Request) The specific problem (missing or invalid email field) A suggested fix (provide a valid email in the correct format) An internal error code for reference A trace ID for further investigation

401 Unauthorized vs 403 Forbidden

In web development, ensuring access control is essential in safely and efficiently managing APIs. The meanings of 401 Unauthorized and 403 Forbidden are sometimes confused. Nonetheless, both codes have to do with restricted resources, but they serve different purposes. In this article, we will explain the codes and instruct you on which one to use.

401 Unauthorized?​ The response is an HTTP error code for a request lacking valid authentication credentials from a client is referred to as the 401 Unauthorized status code. That being said, it means that before accessing the requested resource, it’s necessary for the server to authenticate itself to the client. If no credentials are provided or if wrong ones are given by the client, then what follows is a 401 status code.

When to Use 401 Unauthorized​ Use 401 Unauthorized when: No authentication details have been received yet from the client. The authentication information supplied – username and password/token – is not valid/has expired. There is no authorization header present in your requests like “Authorization.” For instance, if an API demands Bearer token for access but this token has not been included in any request or is incorrect it will issue back a response having HTTP status code 401 Unauthorized (the most common case).

403 Forbidden?​ The reason for using a 403 Forbidden status code is when the server recognizes the request, the client has been authenticated, but the client does not have permission to access the requested resource. It means that in this case, a client is known while a server intentionally turns down fulfilling the request because of inadequate privileges. When to Use 403 Forbidden​ Use 403 Forbidden when: Authenticated clientele lack sufficient permissions to reach given resources. Server denies resource access irrespective of client’s authentication state. Client’s access to resources is prohibited by any form of an access control system. For instance, an authorized user may try accessing an admin only page without having adequate role. Even if one gets logged in, the response will indicate 403 Forbidden if they do not have sufficient rights.