PostgREST / postgrest

REST API for any Postgres database
https://postgrest.org
MIT License
23.43k stars 1.03k forks source link

Swagger schema does not include return types for RPC calls #2180

Open colophonemes opened 2 years ago

colophonemes commented 2 years ago

Environment

Description of issue

(Expected behavior vs actual behavior)

Expected: Swagger API schema has return types on RPC endpoints

Actual: RPC endpoint return types have no return type (i.e. return type void)

(Steps to reproduce: Include a minimal SQL definition plus how you make the request to PostgREST and the response body)

RPC function

CREATE FUNCTION mygreatrpc(name TEXT) RETURNS TEXT AS
$$
    SELECT 'hello ' || $1;
$$
LANGUAGE SQL
SECURITY DEFINER;

Swagger path definition

    "/rpc/mygreatrpc": {
      "post": {
        "tags": ["(rpc) mygreatrpc"],
        "produces": ["application/json", "application/vnd.pgrst.object+json"],
        "parameters": [
          {
            "required": true,
            "schema": {
              "required": [""],
              "type": "object",
              "properties": { "name": { "format": "text", "type": "string" } }
            },
            "in": "body",
            "name": "args"
          },
          { "$ref": "#/parameters/preferParams" }
        ],
        "responses": { 
            "200": { 
                "description": "OK" 
                // EXPECTED: "schema" property with response format
            } 
        }
      }
    },

This makes it impossible to use a generated Swagger client in a strongly-typed language (e.g. Typescript) without unsafe manual casts.

Possibly related to this open issue from 2017: https://github.com/PostgREST/postgrest/issues/1225

colophonemes commented 2 years ago

Relatedly, the Prefer: return=response version of the response is not represented on POST/PATCH endpoints.

For example, a GET endpoint contains both the regular (200) and Prefer: count=exact|estimated|planned (206) response formats:

"/apis": {
      "get": {
        "tags": ["apis"],
        "parameters": [
          { "$ref": "#/parameters/rowFilter.apis.api_id" },
          { "$ref": "#/parameters/rowFilter.apis.name" },
          { "$ref": "#/parameters/select" },
          { "$ref": "#/parameters/order" },
          { "$ref": "#/parameters/range" },
          { "$ref": "#/parameters/rangeUnit" },
          { "$ref": "#/parameters/offset" },
          { "$ref": "#/parameters/limit" },
          { "$ref": "#/parameters/preferCount" }
        ],
        "responses": {
          // correctly shows both response variants
          "206": { "description": "Partial Content" },
          "200": {
            "schema": {
              "items": { "$ref": "#/definitions/apis" },
              "type": "array"
            },
            "description": "OK"
          }
        }
      },
      "post": {
        "tags": ["apis"],
        "parameters": [
          { "$ref": "#/parameters/body.apis" },
          { "$ref": "#/parameters/select" },
          { "$ref": "#/parameters/preferReturn" }
        ],
        // only shows the default variant
        "responses": { "201": { "description": "Created" } }
      }
}

I would expect the POST/PATCH/DELETE endpoints to have these response types available.

tjmcdonough commented 2 weeks ago

Has any progress been made on this?