#note
このツイートが話題になっているのを目にして [RFC9457](https://www.rfc-editor.org/rfc/rfc9457.html) とその前身になっている [RFC7807](https://www.rfc-editor.org/rfc/rfc7807) を読んでみた
RFC のモチベーション
> This specification's aim is to define common error formats for applications that need one so that they aren't required to define their own or, worse, tempted to redefine the semantics of existing HTTP status codes. Even if an application chooses not to use it to convey errors, reviewing its design can help guide the design decisions faced when conveying errors in an existing format.
そもそもこれらの RFC で提案しているフォーマット
```json
HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en
{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/msgs/abc",
"balance": 30,
"accounts": ["/account/12345",
"/account/67890"]
}
```
`type` には URLを指定することでユニークな key をエラーに対して付与することが可能となっていて、原則はこの url に遷移した際にはリカバリーの方法を提供することになっている。
## やや特徴的な仕様 (や主張)
### 複数の理由を返したい場合
以下のようにすることも推奨している
ちなみに上の例の `balance`, `accounts` や下の例の `errors` は extension と呼ばれるカスタムフィールドと呼ばれている
```json
HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
Content-Language: en
{
"type": "https://example.net/validation-error",
"title": "Your request is not valid.",
"errors": [
{
"detail": "must be a positive integer",
"pointer": "#/age"
},
{
"detail": "must be 'green', 'red' or 'blue'",
"pointer": "#/profile/color"
}
]
}
```
### `status` にステータスコードを含める
`status` というフィールドに任意で origin サーバーが発行したステータスコードを含めるという仕様がある。
軽く調べた感じこれに微妙な反応を示している人も多少いたが CDN とか複数のサービスや複雑な経路を辿ったときにクライアントからみたステータスコードが変わっているケースは確かにあるとは思うので納得感はある (しかも任意のフィールドなので)。
### Content-Type が `application/problem+json`
これは少なくとも自分としては受け入れるのが難しいような気がしてしまった。
またこれを導入したいモチベーションも理解しきれていないというのが正直なところ
## RFC7807 からのアップデートは何か
ここが一番しっくりきていないところで [Appendix D. Changes from RFC 7807](https://www.rfc-editor.org/rfc/rfc9457.html#appendix-D) にも以下3点が書かれているものの根本的な前進はないように見える
- [Section 4.2](https://www.rfc-editor.org/rfc/rfc9457.html#registry) introduces a registry of common problem type URIs
- -> 一般的に利用できるエラーの type の URI を提案しているが現状は登録がほとんどない
- [Section 3](https://www.rfc-editor.org/rfc/rfc9457.html#problem-json) clarifies how multiple problems should be treated
- -> extension の利用例を追加している (しかも RFC 7807 時点でも荒いけど配列で返す主張がある)
- [Section 3.1.1](https://www.rfc-editor.org/rfc/rfc9457.html#type) provides guidance for using type URIs that cannot be dereferenced
- -> ステータスコードで説明できているような場合には `type` は `about:blank` でいいよという主張 (しかしすでにこれがデフォルトであることは、 RFC7807 でも提案済み)
## 感想
結論からいうと、考え方は同意する部分が多いものの普及するまでにはまだまだハードルが高そうだなという感覚になった。
そもそも 2025/11 時点では ( [RFC7807](https://www.rfc-editor.org/rfc/rfc7807) は2016に提案されている ) どちらも Proposed Standard になっているというのはありつつ、特にエラーに含む `type` には URL を推奨していて「既存のものを利用してもよい」としているが https://www.iana.org/assignments/http-problem-types/http-problem-types.xhtml に登録されているものがあまりにも少ないので自作する必要があるというのが現状ではある。
また RFC 7807 時点からそんなにアップデートがないという点でも普及するまでのハードルを感じている。
全体を通してユースケースとして確かに外部に広く公開された REST API とかであれば有益な気もしつつ、内部通信には RPC スタイルが好まれる現代においてはなかなかここまで採用するのはむずかしかろうという感想になった。
`type` を URL にしようとか非常に合意できる要素はたくさんあるだけにやや残念な気持ち。