apidocs.swagger.yaml

swagger: "2.0"
info:
  title: An example of generating swagger via gRPC ecosystem.
  version: "1.0"
  contact:
    url: https://github.com/michilu/proto-api
    email: none@example.com
  license:
    name: Apache-2.0
    url: https://github.com/michilu/proto-api/blob/master/LICENSE
tags:
  - name: HealthService
  - name: ExampleService
host: localhost:3100
schemes:
  - http
  - https
consumes:
  - application/json
produces:
  - application/json
paths:
  /v1/example/{id}:
    post:
      operationId: ExampleService_Query
      responses:
        "200":
          description: A successful response.
          schema:
            $ref: '#/definitions/v1ExampleServiceQueryResponse'
      parameters:
        - name: id
          in: path
          required: true
          type: string
          format: uuid
        - name: body
          in: body
          required: true
          schema:
            $ref: '#/definitions/ExampleServiceQueryBody'
      tags:
        - ExampleService
      security:
        - ApiKeyAuth: []
          OAuth2:
            - read
            - write
  /v1/healthCheck:
    get:
      operationId: HealthService_Check
      responses:
        "200":
          description: A successful response.
          schema:
            $ref: '#/definitions/v1CheckResponse'
      parameters:
        - name: service
          description: The service name to check the health of.
          in: query
          required: true
          type: string
      tags:
        - HealthService
definitions:
  CheckResponseServingStatus:
    type: string
    enum:
      - SERVING_STATUS_UNKNOWN_UNSPECIFIED
      - SERVING_STATUS_SERVING
      - SERVING_STATUS_NOT_SERVING
    default: SERVING_STATUS_UNKNOWN_UNSPECIFIED
  ExampleServiceQueryBody:
    type: object
  protov1Status:
    type: object
    properties:
      type:
        type: string
        description: |-
          The "type" member is a JSON string containing a URI reference [URI] that identifies the problem/response type. Consumers MUST use the "type" URI (after resolution, if necessary) as the problem/response type's primary identifier.
          When this member is not present, its value is assumed to be "about:blank".
      status:
        type: integer
        format: int32
        description: |-
          The "status" member is a JSON number indicating the HTTP status code ([HTTP], Section 15) generated by the origin server for this occurrence of the problem/response.
          The HTTP status code that corresponds to `google.rpc.Status.code`.
      title:
        type: string
        description: The "title" member is a JSON string containing a short, human-readable summary of the problem/response type.
      detail:
        type: string
        description: |-
          The "detail" member is a JSON string containing a human-readable explanation specific to this occurrence of the problem/response.
          The "detail" string, if present, ought to focus on helping the client correct the problem/response, rather than giving debugging information.
      instance:
        type: string
        description: The "instance" member is a JSON string containing a URI reference that identifies the specific occurrence of the problem/response.
      extensions:
        type: array
        items:
          type: string
        description: Problem type definitions MAY extend the problem details object with additional members that are specific to that problem type.
      code:
        $ref: '#/definitions/rpcCode'
        description: This is the enum version for `google.rpc.Status.code`.
    title: |-
      Extends [RFC 9457] for API response.
      RFC 9457 - Problem Details for HTTP APIs https://datatracker.ietf.org/doc/html/rfc9457
  rpcCode:
    type: string
    enum:
      - OK
      - CANCELLED
      - UNKNOWN
      - INVALID_ARGUMENT
      - DEADLINE_EXCEEDED
      - NOT_FOUND
      - ALREADY_EXISTS
      - PERMISSION_DENIED
      - UNAUTHENTICATED
      - RESOURCE_EXHAUSTED
      - FAILED_PRECONDITION
      - ABORTED
      - OUT_OF_RANGE
      - UNIMPLEMENTED
      - INTERNAL
      - UNAVAILABLE
      - DATA_LOSS
    default: OK
    description: |-
      The canonical error codes for gRPC APIs.


      Sometimes multiple error codes may apply.  Services should return
      the most specific error code that applies.  For example, prefer
      `OUT_OF_RANGE` over `FAILED_PRECONDITION` if both codes apply.
      Similarly prefer `NOT_FOUND` or `ALREADY_EXISTS` over `FAILED_PRECONDITION`.

       - OK: Not an error; returned on success

      HTTP Mapping: 200 OK
       - CANCELLED: The operation was cancelled, typically by the caller.

      HTTP Mapping: 499 Client Closed Request
       - UNKNOWN: Unknown error.  For example, this error may be returned when
      a `Status` value received from another address space belongs to
      an error space that is not known in this address space.  Also
      errors raised by APIs that do not return enough error information
      may be converted to this error.

      HTTP Mapping: 500 Internal Server Error
       - INVALID_ARGUMENT: The client specified an invalid argument.  Note that this differs
      from `FAILED_PRECONDITION`.  `INVALID_ARGUMENT` indicates arguments
      that are problematic regardless of the state of the system
      (e.g., a malformed file name).

      HTTP Mapping: 400 Bad Request
       - DEADLINE_EXCEEDED: The deadline expired before the operation could complete. For operations
      that change the state of the system, this error may be returned
      even if the operation has completed successfully.  For example, a
      successful response from a server could have been delayed long
      enough for the deadline to expire.

      HTTP Mapping: 504 Gateway Timeout
       - NOT_FOUND: Some requested entity (e.g., file or directory) was not found.

      Note to server developers: if a request is denied for an entire class
      of users, such as gradual feature rollout or undocumented whitelist,
      `NOT_FOUND` may be used. If a request is denied for some users within
      a class of users, such as user-based access control, `PERMISSION_DENIED`
      must be used.

      HTTP Mapping: 404 Not Found
       - ALREADY_EXISTS: The entity that a client attempted to create (e.g., file or directory)
      already exists.

      HTTP Mapping: 409 Conflict
       - PERMISSION_DENIED: The caller does not have permission to execute the specified
      operation. `PERMISSION_DENIED` must not be used for rejections
      caused by exhausting some resource (use `RESOURCE_EXHAUSTED`
      instead for those errors). `PERMISSION_DENIED` must not be
      used if the caller can not be identified (use `UNAUTHENTICATED`
      instead for those errors). This error code does not imply the
      request is valid or the requested entity exists or satisfies
      other pre-conditions.

      HTTP Mapping: 403 Forbidden
       - UNAUTHENTICATED: The request does not have valid authentication credentials for the
      operation.

      HTTP Mapping: 401 Unauthorized
       - RESOURCE_EXHAUSTED: Some resource has been exhausted, perhaps a per-user quota, or
      perhaps the entire file system is out of space.

      HTTP Mapping: 429 Too Many Requests
       - FAILED_PRECONDITION: The operation was rejected because the system is not in a state
      required for the operation's execution.  For example, the directory
      to be deleted is non-empty, an rmdir operation is applied to
      a non-directory, etc.

      Service implementors can use the following guidelines to decide
      between `FAILED_PRECONDITION`, `ABORTED`, and `UNAVAILABLE`:
       (a) Use `UNAVAILABLE` if the client can retry just the failing call.
       (b) Use `ABORTED` if the client should retry at a higher level
           (e.g., when a client-specified test-and-set fails, indicating the
           client should restart a read-modify-write sequence).
       (c) Use `FAILED_PRECONDITION` if the client should not retry until
           the system state has been explicitly fixed.  E.g., if an "rmdir"
           fails because the directory is non-empty, `FAILED_PRECONDITION`
           should be returned since the client should not retry unless
           the files are deleted from the directory.

      HTTP Mapping: 400 Bad Request
       - ABORTED: The operation was aborted, typically due to a concurrency issue such as
      a sequencer check failure or transaction abort.

      See the guidelines above for deciding between `FAILED_PRECONDITION`,
      `ABORTED`, and `UNAVAILABLE`.

      HTTP Mapping: 409 Conflict
       - OUT_OF_RANGE: The operation was attempted past the valid range.  E.g., seeking or
      reading past end-of-file.

      Unlike `INVALID_ARGUMENT`, this error indicates a problem that may
      be fixed if the system state changes. For example, a 32-bit file
      system will generate `INVALID_ARGUMENT` if asked to read at an
      offset that is not in the range [0,2^32-1], but it will generate
      `OUT_OF_RANGE` if asked to read from an offset past the current
      file size.

      There is a fair bit of overlap between `FAILED_PRECONDITION` and
      `OUT_OF_RANGE`.  We recommend using `OUT_OF_RANGE` (the more specific
      error) when it applies so that callers who are iterating through
      a space can easily look for an `OUT_OF_RANGE` error to detect when
      they are done.

      HTTP Mapping: 400 Bad Request
       - UNIMPLEMENTED: The operation is not implemented or is not supported/enabled in this
      service.

      HTTP Mapping: 501 Not Implemented
       - INTERNAL: Internal errors.  This means that some invariants expected by the
      underlying system have been broken.  This error code is reserved
      for serious errors.

      HTTP Mapping: 500 Internal Server Error
       - UNAVAILABLE: The service is currently unavailable.  This is most likely a
      transient condition, which can be corrected by retrying with
      a backoff. Note that it is not always safe to retry
      non-idempotent operations.

      See the guidelines above for deciding between `FAILED_PRECONDITION`,
      `ABORTED`, and `UNAVAILABLE`.

      HTTP Mapping: 503 Service Unavailable
       - DATA_LOSS: Unrecoverable data loss or corruption.

      HTTP Mapping: 500 Internal Server Error
  v1CheckResponse:
    type: object
    properties:
      status:
        $ref: '#/definitions/CheckResponseServingStatus'
        description: The serving status of the health check.
    description: The response message containing the health status of the service.
    title: CheckResponse
    required:
      - status
  v1ExampleServiceQueryResponse:
    type: object
    properties:
      status:
        $ref: '#/definitions/protov1Status'
securityDefinitions:
  ApiKeyAuth:
    type: apiKey
    name: X-API-Key
    in: header
  OAuth2:
    type: oauth2
    flow: accessCode
    authorizationUrl: https://example.com/oauth/authorize
    tokenUrl: https://example.com/oauth/token
    scopes:
      admin: Grants read and write access to administrative information
      read: Grants read access
      write: Grants write access
security:
  - ApiKeyAuth: []
    OAuth2:
      - read
      - write