Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

JSON:API: 404/405 router errors are empty, and error objects have a non-spec `type` member

オープン
#8,704 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
50/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
php, symfony
領域
api

調査の方向性

Start with JsonApi\Serializer\ErrorNormalizer in src/JsonApi/Serializer and reproduce with the Novel resource from the issue. Compare the bodies of GET /nope, DELETE /novels/1 and GET /novels/999 to find where the non-operation errors lose their status, title and detail. Done when the 404 and 405 errors carry the same members as the operation errors, and no error object has a type member while links.type remains.

索引モデルが issue の本文から書いたものです。

説明

API Platform version(s) affected

4.4.4

Description

The JSON:API error documents have two problems that remain after #8366 (which makes status a string on main).

  1. Errors that do not come from an operation are empty. An unknown route (404) or a method that is not allowed (405) answers with an error object that has only a generated id. It has no status, title or detail:

    {"errors":[{"id":"/.well-known/genid/1d2136a82a8b3a05d6a2"}]}
    
  2. Error objects have a type member. The spec lists the members of an error object (id, links, status, code, title, detail, source, meta), and "Unless otherwise noted, objects defined by this specification or any applied extensions MUST NOT contain any additional members." JsonApi\Serializer\ErrorNormalizer copies the problem type to links.type, which is correct, but it also keeps it as a type member:

    {"errors":[{"id":"/errors/404","title":"An error occurred","detail":"Not Found","status":404,"type":"/errors/404","links":{"type":"/errors/404"},"code":"404"}]}
    

#3042 is about the older problem+json format. These two problems are in the current errors format.

How to reproduce
#[ApiResource(operations: [
    new Get(provider: [self::class, 'provide']),
    new Post(processor: [self::class, 'process']),
])]
final class Novel
{
    public int $id = 1;
    public string $title = 'Dune';

    public static function provide(): ?self { return null; }
    public static function process(self $data, Operation $operation): self { return $data; }
}
Request Status Body
GET /nope 404 {"errors":[{"id":"/.well-known/genid/…"}]}
DELETE /novels/1 405 {"errors":[{"id":"/.well-known/genid/…"}]}
GET /novels/999 404 {"errors":[{"id":"/errors/404","title":"An error occurred","detail":"Not Found","status":404,"type":"/errors/404","links":{"type":"/errors/404"},"code":"404"}]}
POST /novels with {"data":{"type":"Novel","attributes":{"title":5}}} 400 {"errors":[{"id":"/errors/400","title":"An error occurred","detail":"The type of the \"title\" attribute must be \"string\", \"integer\" given.","status":400,"type":"/errors/400","links":{"type":"/errors/400"},"code":"400"}]}

Expected:

  • The 404 and 405 errors have the same members as the other errors: status, title, detail, code and links.type.
  • Error objects have no type member. The value stays in links.type.
Additional Context

Checked on api-platform/core v4.4.4, Symfony 7.4, PHP 8.5, in an empty Symfony app. The related code in src/JsonApi/Serializer is the same on main, except for the error status cast (#8366).

The app has only FrameworkBundle, TwigBundle and ApiPlatformBundle, with this config:

$c->extension('api_platform', [
    'mapping' => ['paths' => ['%kernel.project_dir%/src/ApiResource']],
    'formats' => ['jsonapi' => ['application/vnd.api+json']],
    'error_formats' => ['jsonapi' => ['application/vnd.api+json'], 'jsonproblem' => ['application/problem+json']],
    'doctrine' => ['enabled' => false],
]);

All requests send Accept: application/vnd.api+json and, when they have a body, Content-Type: application/vnd.api+json. The responses are from the prod environment.

主要言語
PHP
スター
2.6k
フォーク
989
平均マージ
2日 1時間
マージ済み PR(30日)
104

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

api-platform/core のほかの issue

api-platform/core の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。