fix: include response schemas that has no application/ prefixed content-typent-type

[LumaKernel]

Types of changes

• Bugfix

Input(swagger2.0)

<proj-root>/samples/swagger.yaml に追記しました。

# ...
  /hello:
    get:
      produces:
        - text/plain
      parameters:
        - name: name
          required: false
          type: string
          in: query
          description: defaults to World if not given
      operationId: getGreeting
      responses:
        200:
          description: returns a greeting
          schema:
              type: string
              description: contains the actual greeting as plain text

Actual

/* eslint-disable */
export type Methods = {
  get: {
    query?: {
      /** defaults to World if not given */
      name?: string
    }

    status: 200
  }
}

Expected

<proj-root>/samples/swagger/hello/index.ts にあります。

/* eslint-disable */
export type Methods = {
  get: {
    query?: {
      /** defaults to World if not given */
      name?: string
    }

    status: 200
+   /** returns a greeting */
+   resBody: string
  }
}

原因

application/... 以外の content type のレスポンス定義を拾えない

このPRでの対策

まず後方互換で application/... があれば優先。
次に、何でもいいからあればそれを使う。例えば text/plain でも何でも。

代案

代案というか、その他一緒にするといいかもしれない案。
x-aspida1-content-type みたいなのを指定できるようにして、Aspida v1 のうちは指定できるようにするとか。

x-aspida1-status: 201 みたいなのも考えられる。

x-... は go の OpenAPI 関連ツールで使われているのを見かけた。変数名を強制するとか。
OpenAPI 上の spec では OpenAPI Extensions として定義されている。

Aspida v1 でどこまで面倒見るかは Aspida v2 の具合にもよりそうです…

# ...
      responses:
        200:
          x-aspida1-content-type: 'text/plain'
          description: returns a greeting
          schema:
              type: string
              description: contains the actual greeting as plain text

[LumaKernel]

どの content-type でも全部返ってくる可能性があると考えて、全部の or にするのがもう少し厳格な気がしてきました。
.json() < .text() < .blob() の強さの順で吸収されるようにする、と一応すべてのケースに対応できそう…？

https://swagger.io/specification/#data-types を参考にアルゴリズムを整理すると、

• トップレベルが type: string →
  • schema の format: が binary → blob()
  • schema の format: が byte → text() (して base64 decode (aspida v1 incompatible))
  • format: なし → text()
  • その他 → text() (か、 Date 系はもしかしたら面倒見れるかも…？ (aspida v1 incompatible))
• トップレベルが boolean, integer, number → .json()
  • ただし int64 は表現できない。 bigint にするとか…？ (aspida v1 incompatible)
• else →
  • json()

とかでしょうか

fetch のデフォルトが Accept: */* で、 axios のデフォルトが Accept: application/json, text/plain, */* なので text/plain, text/html で定義されていると text/plain が帰ってきてほしい感じはあります…

[solufa]

これ全く気付きませんでした、ありがとうございます！
テストちゃんと書かれていて安心できますね、LGTM