回答編集履歴
6
テキスト修正
answer
CHANGED
|
@@ -151,5 +151,5 @@
|
|
|
151
151
|
**503 Service Unavailable — サービス停止**
|
|
152
152
|
|
|
153
153
|
私見ですが、とりあえず上記９個は覚えておき、適切に使い分けられるようにして、
|
|
154
|
-
どれにも当てはまらない状況のときは、ステータスコード一覧を調べてみる、
|
|
154
|
+
どれにも当てはまらないように思える状況のときは、ステータスコード一覧を調べてみる、
|
|
155
|
-
という対応で十分ではないかと思います。
|
|
155
|
+
という対応で、まずは十分ではないかと思います。
|
5
テキスト修正
answer
CHANGED
|
@@ -68,7 +68,7 @@
|
|
|
68
68
|
**補足 2**
|
|
69
69
|
|
|
70
70
|
ステータスコードの200番台系、400番台系、500番台系のうち、どれを返せば良いか？について、
|
|
71
|
-
極めて現場的なやり方の一例を示します。（※ウォータフォールではなくアジャイルです）
|
|
71
|
+
極めて現場的なやり方の一例を示します。（※ウォーターフォールではなく、アジャイルです）
|
|
72
72
|
|
|
73
73
|
まず、
|
|
74
74
|
|
|
@@ -85,12 +85,14 @@
|
|
|
85
85
|
|
|
86
86
|
と考えていくわけですが、このとき、具体的に何番にしたらよいか分からないときは、
|
|
87
87
|
|
|
88
|
-
> リクエストに問題がある場合は、**とりあえず**
|
|
88
|
+
> リクエストに問題がある場合は、**とりあえず** すべて400 Bad Request を返すことに
|
|
89
|
-
必要に応じて後で詳細化する
|
|
89
|
+
しておいて、必要に応じて後で詳細化する
|
|
90
90
|
|
|
91
|
+
ことにします。
|
|
91
|
-
|
|
92
|
+
同様にサーバー側に起因するエラーの場合、細かく分ければ違う状況でも、とりあえず
|
|
92
|
-
500 Internal Server Error を返すことにし、同様に、成功の場合は、200 OK だけを
|
|
93
|
+
500 Internal Server Error だけを返すことにし、同様に、成功の場合は、200 OK だけを
|
|
93
|
-
という設計にしておいて、これに基づいて、サーバー側と、(JQueryなどで）フロントエンド
|
|
94
|
+
返す、という設計にしておいて、これに基づいて、サーバー側と、(JQueryなどで）フロントエンド側を
|
|
95
|
+
実装していきます。
|
|
94
96
|
|
|
95
97
|
つまり、
|
|
96
98
|
|
|
@@ -100,23 +102,23 @@
|
|
|
100
102
|
|
|
101
103
|
その後、たとえば、
|
|
102
104
|
|
|
103
|
-
__ログインしている状態でのみアクセス可能なリソース取得や更新をログインしていない状態
|
|
105
|
+
__ログインしている状態でのみアクセス可能なリソース取得や更新をログインしていない状態__
|
|
104
|
-
__クライアント側でログインページを表示させたいので、他の 400 Bad
|
|
106
|
+
__で試みた場合は、クライアント側でログインページを表示させたいので、他の 400 Bad Request__
|
|
105
|
-
|
|
107
|
+
__のケースと分ける意味で、401 Unauthorized を返させよう。__
|
|
106
108
|
|
|
107
109
|
だとか、あるいは
|
|
108
110
|
|
|
109
111
|
__ログインしているユーザーの権限レベルでは禁止されているリクエストを受けたときは、__
|
|
110
112
|
__403 Forbidden を返させよう。__
|
|
111
113
|
|
|
112
|
-
だとか、必要に応じて分けていき、その詳細化に応じてサーバーとフロントで実装を追加す
|
|
114
|
+
だとか、必要に応じて分けていき、その詳細化に応じてサーバーとフロントで実装を追加します。
|
|
113
|
-
逆にいえば
|
|
115
|
+
逆にいえば、
|
|
114
116
|
|
|
115
|
-
__リクエスト不正の場合は、ステータスコードは400だけ
|
|
117
|
+
__リクエスト不正の場合は、ステータスコードは400だけを使い、詳細はレスポンスボディに記述することにしよう。__
|
|
116
118
|
|
|
117
119
|
という設計も、（いいか悪いかは別として、可能か不可能かでいえば、）出来なくはない、ということになります。
|
|
118
120
|
|
|
119
|
-
また、成功の場合も同様で、初めは全て、200 OK を返すことにしていたけれど、何かの理由で
|
|
121
|
+
また、成功の場合も同様で、初めは全て、200 OK を返すことにしていたけれど、何かの理由で
|
|
120
122
|
|
|
121
123
|
__POST で何らかのリソースを新規作成することに成功したことを、他のリクエストの成功とは__
|
|
122
124
|
__区別したいので、その場合は、201 Created を返させよう。__
|
|
@@ -148,5 +150,6 @@
|
|
|
148
150
|
**500 Internal Server Error — サーバ内部エラー**
|
|
149
151
|
**503 Service Unavailable — サービス停止**
|
|
150
152
|
|
|
151
|
-
私見ですが、とりあえず上記９個
|
|
153
|
+
私見ですが、とりあえず上記９個は覚えておき、適切に使い分けられるようにして、
|
|
152
|
-
状況のときは、ステータスコード一覧を調べてみる、
|
|
154
|
+
どれにも当てはまらない状況のときは、ステータスコード一覧を調べてみる、
|
|
155
|
+
という対応で十分ではないかと思います。
|
4
テキスト追加
answer
CHANGED
|
@@ -58,8 +58,95 @@
|
|
|
58
58
|
以上、参考になれば幸いです。
|
|
59
59
|
|
|
60
60
|
---
|
|
61
|
-
補足
|
|
61
|
+
**補足 1**
|
|
62
62
|
|
|
63
63
|
APIの設計時に、レスポンスコードに何を返すか？というのは、個人の考え方により、意見の分かれる
|
|
64
64
|
ところですので、最終的には、レスポンスコードの一覧を見たうえで、質問者様が
|
|
65
|
-
「これがよさそう」と思うところを選べばよろしいかと思います。
|
|
65
|
+
「これがよさそう」と思うところを選べばよろしいかと思います。
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
**補足 2**
|
|
69
|
+
|
|
70
|
+
ステータスコードの200番台系、400番台系、500番台系のうち、どれを返せば良いか？について、
|
|
71
|
+
極めて現場的なやり方の一例を示します。（※ウォータフォールではなくアジャイルです）
|
|
72
|
+
|
|
73
|
+
まず、
|
|
74
|
+
|
|
75
|
+
- 成功の場合 → 200番台系
|
|
76
|
+
- 失敗の場合：
|
|
77
|
+
・リクエスト側に原因あり→ 400番台系
|
|
78
|
+
・サーバー側に原因あり→ 500番台系
|
|
79
|
+
|
|
80
|
+
と分けられますが、リクエスト側に原因あり（400番台系）のケースとして、Aという状況と、
|
|
81
|
+
Bという状況の２つあった場合、
|
|
82
|
+
|
|
83
|
+
__Aによるエラーと、Bによるエラーは、ともにリクエストに原因があるので、400番台系を返させることは__
|
|
84
|
+
__決まっているが、Aの場合は何番で、Bの場合は何番にしたらよいだろう？__
|
|
85
|
+
|
|
86
|
+
と考えていくわけですが、このとき、具体的に何番にしたらよいか分からないときは、
|
|
87
|
+
|
|
88
|
+
> リクエストに問題がある場合は、**とりあえず**、 すべて400 Bad Request を返させることにしておいて、
|
|
89
|
+
必要に応じて後で詳細化する。
|
|
90
|
+
|
|
91
|
+
ということにします。同様にサーバー側に起因するエラーの場合、細かく分ければ違う状況でも、とりあえず
|
|
92
|
+
500 Internal Server Error を返すことにし、同様に、成功の場合は、200 OK だけを返させる
|
|
93
|
+
という設計にしておいて、これに基づいて、サーバー側と、(JQueryなどで）フロントエンド 側を実装します。
|
|
94
|
+
|
|
95
|
+
つまり、
|
|
96
|
+
|
|
97
|
+
- （200番台,400番台,500番台を返すべき状況では、）200, 400, 500 だけしか使わない
|
|
98
|
+
|
|
99
|
+
という、ざっくりな設計で**とりあえず**始めます。
|
|
100
|
+
|
|
101
|
+
その後、たとえば、
|
|
102
|
+
|
|
103
|
+
__ログインしている状態でのみアクセス可能なリソース取得や更新をログインしていない状態で試みた場合は、__
|
|
104
|
+
__クライアント側でログインページを表示させたいので、他の 400 Bad Request のケースと分ける意味で、__
|
|
105
|
+
__401 Unauthorized を返させよう。__
|
|
106
|
+
|
|
107
|
+
だとか、あるいは
|
|
108
|
+
|
|
109
|
+
__ログインしているユーザーの権限レベルでは禁止されているリクエストを受けたときは、__
|
|
110
|
+
__403 Forbidden を返させよう。__
|
|
111
|
+
|
|
112
|
+
だとか、必要に応じて分けていき、その詳細化に応じてサーバーとフロントで実装を追加すればよいです。
|
|
113
|
+
逆にいえば
|
|
114
|
+
|
|
115
|
+
__リクエスト不正の場合は、ステータスコードは400だけにして、詳細はレスポンスボディに記述することにしよう。__
|
|
116
|
+
|
|
117
|
+
という設計も、（いいか悪いかは別として、可能か不可能かでいえば、）出来なくはない、ということになります。
|
|
118
|
+
|
|
119
|
+
また、成功の場合も同様で、初めは全て、200 OK を返すことにしていたけれど、何かの理由で、
|
|
120
|
+
|
|
121
|
+
__POST で何らかのリソースを新規作成することに成功したことを、他のリクエストの成功とは__
|
|
122
|
+
__区別したいので、その場合は、201 Created を返させよう。__
|
|
123
|
+
|
|
124
|
+
といった感じで詳細化していきます。
|
|
125
|
+
|
|
126
|
+
---
|
|
127
|
+
**補足 3**
|
|
128
|
+
|
|
129
|
+
ご質問のタイトルである、「httpステータスコードについて」、
|
|
130
|
+
|
|
131
|
+
> どのような値をサーバーから返したほうがよいのでしょうか？
|
|
132
|
+
|
|
133
|
+
に応える良書を一冊挙げます。
|
|
134
|
+
|
|
135
|
+
[Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)](https://www.amazon.co.jp/dp/4774142042/)
|
|
136
|
+
|
|
137
|
+
以下は、上記の書籍の目次、「第８章 ステータスコード」から引用しました。
|
|
138
|
+
|
|
139
|
+
> **8.4 よく使われるステータスコード**
|
|
140
|
+
|
|
141
|
+
> **200 OK — リクエスト成功**
|
|
142
|
+
**201 Created — リソースの作成成功**
|
|
143
|
+
**301 Moved Permanently — リソースの恒久的な移動**
|
|
144
|
+
**303 See Other — 別URIの参照**
|
|
145
|
+
**400 Bad Request ー リクエストの間違い**
|
|
146
|
+
**401 Unauthorized — アクセス権不正**
|
|
147
|
+
**404 Not Found — リソースの不在**
|
|
148
|
+
**500 Internal Server Error — サーバ内部エラー**
|
|
149
|
+
**503 Service Unavailable — サービス停止**
|
|
150
|
+
|
|
151
|
+
私見ですが、とりあえず上記９個を覚えておいて適切に使い分けることができ、どれにも当てはまらない
|
|
152
|
+
状況のときは、ステータスコード一覧を調べてみる、という対応で十分ではないかと思います。
|
3
テキスト追加
answer
CHANGED
|
@@ -55,4 +55,11 @@
|
|
|
55
55
|
に書かれています。
|
|
56
56
|
|
|
57
57
|
|
|
58
|
-
以上、参考になれば幸いです。
|
|
58
|
+
以上、参考になれば幸いです。
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
補足
|
|
62
|
+
|
|
63
|
+
APIの設計時に、レスポンスコードに何を返すか？というのは、個人の考え方により、意見の分かれる
|
|
64
|
+
ところですので、最終的には、レスポンスコードの一覧を見たうえで、質問者様が
|
|
65
|
+
「これがよさそう」と思うところを選べばよろしいかと思います。
|
2
テキスト修正
answer
CHANGED
|
@@ -19,11 +19,14 @@
|
|
|
19
19
|
|
|
20
20
|
です。これは成功を表すステータスコードで、この場合、
|
|
21
21
|
レスポンスボディは空にするのがお約束です。
|
|
22
|
-
204を返すケースの例としては、何らかの
|
|
22
|
+
204を返すケースの例としては、何らかのリソースをPOSTで新規
|
|
23
|
-
|
|
23
|
+
作成を要求したときに、その要求が成功して、特にレスポンスボディを
|
|
24
|
-
リクエストの形式としては何ら不正はなく、検索も実行できた上で、何も返さないことも
|
|
25
|
-
|
|
24
|
+
返す必要がないときに使うことがあります。
|
|
26
25
|
|
|
26
|
+
また、GETリクエストにクエリパラメータを与えて、リソースの検索をした結果、
|
|
27
|
+
検索は正常に行われたけれども、該当するものがなく、レスポンスボディとして
|
|
28
|
+
空を返したい場合にも用いられることがあります。
|
|
29
|
+
|
|
27
30
|
上記をふまえご質問の
|
|
28
31
|
|
|
29
32
|
> マスタ無しエラー
|
1
テキスト追加
answer
CHANGED
|
@@ -3,8 +3,8 @@
|
|
|
3
3
|
「リクエストされたURLによるリソースが存在しない」
|
|
4
4
|
|
|
5
5
|
ということを、定義上、明確に示している（＝ステータスコードのメッセージ部分に、
|
|
6
|
-
「存在しない」意味のテキストが含まれている。）ようなステータスコードとして
|
|
6
|
+
「存在しない」意味のテキストが含まれている。）ようなステータスコードとして、
|
|
7
|
-
よく使
|
|
7
|
+
よく使われるものが２つあり、時と場合に応じてより適切なほうを選ぶとよいかと思います。
|
|
8
8
|
|
|
9
9
|
- １つは、存在しないリソースを要求するリクエストをしたこと自体がエラーであることを明示したい場合は
|
|
10
10
|
|