Api-blueprint: 同じリソースで同じHTTP動詞の複数のアクションが必要です（ただし、リクエストのコンテンツタイプは異なります）

更新：私は1つの応答を述べるだけでこれを行うことができると思います：

FORMAT: 1A
# multiple posts?
## Try to make two posts [/v1/whatever]
### POST
+ Request JSON (application/json)
        { nil: nil }
+ Request DNS (text/dns)
        whatever
+ Response 204

ただし、これは埋め込みモードでは正しく表示されません（1つのリクエストタイプのみが表示されます）。 エディター内のプレビュービューとドキュメントビューは優れています。

@jrep

これは、現在の養蜂場の埋め込み（デザイン）ではつまらないようです。 この問題について@apiaryioチームに通知し

@jrepは、複数の応答をサポートするためのここでの要求（埋め込みの制限の隣）ですか？

もしそうなら、以下はすでに有効であるはずです：

FORMAT: 1A

## Try to make two posts [/v1/whatever]

### POST

+ Request JSON (application/json)

        JSON

+ Response 200 (application/json)

        JSON       

+ Request DNS (text/dns)

        whatever

+ Response 200 (text/dns)

        whatever

あなたの例は、複数の要求を示してい応答のみを示しています。 それは私の例のようです。 はい、それは構文的には有効ですが、表現する必要があるものを表現することはできません。

はい：ここで必要なのは、リクエストごとに異なる「応答200」を表示することです。 応答コンテンツタイプは要求コンテンツタイプと一致します（したがって、2つの要求コンテンツタイプは2つの応答コンテンツタイプを意味します）が、2つの応答の情報も完全に同等ではありません。

レガシー形式では、1つの要求とその応答を定義し、次に次の要求と応答のペアを定義しました。 これは新しい形式の構文エラーであり、これを言う有効な方法はないようです。

更新：おっと、私は十分に近くに見えませんでした：あなたの例は少なくとも2つの点で私のものとは異なります：2つの応答と名前付きリクエストの使用。 今それを試してみてください。

@jrep

どういう意味かわかりません。 レガシーブループリントのスニペットをここに送信していただけますか？

Githubチケットではテキストを添付できません。 レガシーブループリントはhttps://dev-staging.akamai.com/api/luna/config-dns/blueprint.apibから入手でき

とった

POST /v1/zones/{zone}
> Content-Type: application/json
... some data ...
< 204
< Location: /v1/zones/example.com

POST /v1/zones/{zone}
> Content-Type: text/dns
... some other data ...
< 204
< Location: /v1/zones/example.com

これを次のように表現しても基本的には問題ないと思います。

## Zone [/v1/zones/{zone}]

### Create [POST]

+ Request Create with JSON (application/json)

        { ... json data ... }

+ Request Create with DNS (text/dns)

        ... dns data ...

+ Response 204
    + Headers

            Location: /v1/zones/example.com

http://docs.multirequest.apiary.io

これは古典的なコンテントネゴシエーションの例です。 応答に本文がなく、OK（およびおそらくそれへのリンク）と表示されている間に、さまざまな表現からリソースを作成します。

これに対応するコンテンツネゴシエーションは次のようになります。

### Retrieve [GET]

+ Request Rerieve JSON representation
    + Headers

            Accept: application/json

+ Response 200 (application/json)

        { ... json data ... }

+ Request Rerieve DNS representation
    + Headers

            Accept: text/dns

+ Response 200 (text/dns)

        ... dns data ...

コンテンツタイプは異なるが同じ意味を持つ（リソースを作成する）複数のリクエストに対する1つのボディレス応答は、優れた設計だと思います。 ただし、 https：//github.com/apiaryio/snowcrash/issues/53の実装により、この制限（同じステータスとコンテンツタイプの複数の応答がある場合の警告）を解除したいと思い

@jrepこの問題はhttps://github.com/apiaryio/snowcrash/issues/53（Snow Crash v0.10.0）で対処されたため、終了します。 コメントして、必要に応じて再開してください。

エンドポイントには複数のトランザクションの例がありますが、 apiaryio / snowcrash＃53に見られるように、これらは

次の例を見てください...

/oauth2/authorizeがあり、仕様により、さまざまなシナリオ（更新からアクセストークンを取得する、パスワードからトークンを生成するなど）を処理します。 これらをAPIドキュメントの単一のアクションにマージすることは、読者が理解するのが非常に困難です。代わりに、ユーザーがサイドメニューに「アクセストークンの更新」や「ユーザーの認証」などの複数のエンドポイントを設定する方が簡単です。 ただし、同じメソッドとURLの組み合わせを2回指定することはできないため、これは不可能です。

これは、API仕様が開発者に特定のアプローチの使用を強制している典型的な例であり、上記のような場合、一般的なデザインパターンに適合しません。

構文のハイライトが正しくありません- Bodyの色を参照してください：