Proposal - Unifying Status and Results in API 2.0

This proposal is in line with my earlier remarks on simplification. 😄

The API is already highly flexible, notably by supporting both synchronous and asynchronous modes, as well as return preference.

I find it excessive to define two distinct schemas (statusInfo and results). A simpler and more consistent design would be to include results within statusInfo, as most processing and workflow engine APIs do.

My proposition for API 2.0 would be:

allOf:
  - $ref: "./descriptionType.yaml"
  - type: object
    required:
      - id
      - status
      - type
    properties:
      id:
        type: string
      processID:
        type: string
        format: uri
      type:
        type: string
        example:
          - process
          - wps
          - openeo
      request:
        oneOf:
          - type: string
          - type: object
          - $ref: "../common-core/link.yaml"
      status:
        $ref: "statusCode.yaml"
      results:
        $ref: "./results.yaml"

...

Review the proposed schema alongside the referenced descriptionType.yaml, statusCode.yaml, results.yaml, and ../common-core/link.yaml definitions. Compare the existing statusInfo and results schemas, then determine whether API 2.0 should incorporate results into statusInfo and update the related specification consistently.