400 エラーの記事一覧

冒頭まとめ GitHub API の 400 Bad Request は、リクエストの形式そのものが壊れていて、サーバーが中身の検証に進めない場合に返されます。公式ドキュメントが 400 として挙げているのは、リクエスト本文が JSON として読めない（Problems parsing JSON）、本文が JSON オブジェクトの形になっていない（Body should be a JSON object）、API バージョン指定のヘッダーに存在しない値を指定した、の3つです。 一方、JSON としては正しく読めたうえで、必須パラメータが足りない・値が仕様に合わないという場合に返るのは、400 ではなく 422 Unprocessable Entity です。400 の調査で最初にすべきことは、設定やパラメータの見直しではなく、応答の message を読んで 400 と 422 のどちらの問題かを確定することです。400 は形式の問題なので、同じリクエストを再試行しても結果は変わりません。修正が必要です。 エラーの概要 GitHub API の 400 の応答本文は次の形です。 { "message": "Problems parsing JSON", "documentation_url": "https://docs.github.com/rest" } 公式のトラブルシューティング文書は、400 と 422 の境界を明確に定めています。リクエスト本文に不正な JSON を送ると 400 と Problems parsing JSON が返ります。エンドポイントが JSON オブジェクトを期待しているのに本文がその形になっていないと 400 と Body should be a JSON object が返ります。これに対し、必須パラメータの省略やパラメータの型の誤りは 422 と Invalid request、リクエストを処理できない場合は 422 と Validation Failed です。つまり「JSON として読めるかどうか」が 400 と 422 のおおまかな境界線です。 ...