API Guidelines
  • adidas API Guidelines
  • General Guidelines
    • Introduction
    • API First
    • Contract
    • Immutability
    • Robustness
    • Common Data Types
    • Version Control System
    • Minimal API Surface
    • Rules for Extending
    • JSON
    • Security
    • Tooling
  • REST API Guidelines
    • Introduction
    • Core REST Principles
      • OpenAPI Specification
      • API Design Platform
      • Design Maturity
      • Testing
    • Protocol
      • HTTP
      • TLS
      • Separate Concerns
      • Request Methods
      • Status Codes
    • Message
      • Message Formats
      • Content Negotiation
      • HAL
      • Problem Detail
      • Foreign Key Relations
    • Application
      • Corporate Data Model
      • Common Data Types
    • Execution
      • Pagination
      • Long Running Tasks
        • Polling
        • Callback
        • Files Upload
      • Batch Operations
      • Search Requests
      • Query Requests with Large Inputs
      • Choosing Fields and Embedded Resources
      • Localization
      • Rate Limiting
      • Caching
      • Testing Enviroments
    • Evolution
      • Naming Conventions
      • Reserved Identifiers
      • URI Structure
      • Changes and Versioning
      • Phasing out Old Versions
    • Guides
      • API Testing CI Environment
      • Complete API Development
    • API Clients
      • Loose Coupling
    • Further References
  • Asynchronous API Guidelines
    • Introduction
    • Core Asynchronous Principles
      • Event Driven Architectures
      • Messages
        • Commands
        • Queries
        • Events
          • Events as Notifications
          • Events to Replicate Data
      • Protocols
      • Coupling
      • Bounded Context
      • Stream Processing
      • Naming Conventions
      • Tooling
        • Editors
        • Command Line Interface (CLI)
        • Generators
    • Kafka Asynchronous Guidelines
      • Introduction
        • Why AsyncAPI?
      • AsyncAPI Version
      • Internal vs Public Specifications
      • Key/Value Format
      • Message Headers
      • Specification Granularity
      • Self-Contained Specifications
        • Meaningful Descriptions
      • Schema Data Evolution
        • Backward Compatibility
        • Forward Compatibility
        • Full Compatibility
      • Automatic Schema Registration
      • Contact Information
      • AsyncAPI ID
      • Servers
      • Channels
      • Schemas
      • Security Schemes
      • External Docs
Powered by GitBook
On this page
  • Example
  • Alternative Design
  • Example
  1. REST API Guidelines
  2. Execution

Search Requests

A search (filter) operation on a collection resource SHOULD be defined as safe, idempotent and cacheable, therefore using the GET HTTP request method.

Every search parameter SHOULD be provided in the form of a query parameter. In the case of search parameters being mutually exclusive or require the presence of another parameter, the explanation MUST be part of operation's description.

Example

A collection of orders can be filtered by either article id it includes or by article manufacturer id. The two parameters are mutually exclusive and cannot be used together. The API description for such a design should look as follows:

paths:
  /orders:
    x-summary: Collection of Orders

    get:
      summary: Retrieve or Search in the Collection of Orders
      description: | 

        This operation allows to retrieve a filtered list of orders based on multiple criteria:

        1. **Filter Orders by Article Id**
        2. **Filter Orders by Manufacturer Id**

      parameters:
        - name: article_id
          in: query
          description: | 
            Article Id. Denotes the id of an article that must be in the order.

            **Mutually exclusive** with `manufacturer_id`.

          required: false
          type: string
          x-example: article_id_1

        - name: manufacturer_id
          in: query
          description: |
            Manufacturer Id. Denotes an id of a manufacturer of an article that must be in the order.

            **Mutually exclusive** with `article_id`.

          required: false
          type: string
          x-example: manufacturer_id_1

Alternative Design

When it would be beneficial (e.g. one of the filter queries is more common than another one) a separate resource for the particular query SHOULD be provided. In such a case, the pivotal search parameter MAY be in the form of a path variable.

Example

Building on top of the example mentioned above, we will provide the filtering of orders by article id as a separate resource.

paths:
  /articles/{article_id}/orders:
    x-summary: Collection of Orders for given Article 

    get:
      summary: Retrieve the collection of Orders that contain given article.
PreviousBatch OperationsNextQuery Requests with Large Inputs

Last updated 6 years ago