上記ステータスコードは、Interstage AR Processing Serverが返すコードです。以下のようなコードはInterstage AR Processing Serverではなく、WEBサーバ/JavaEE実行環境が返す場合があります。 「401 Unauthorized」等のHTTPの正常系ステータスコード。 HTTPメッセージフォーマット/パスフォーマット/JSONフォーマット/値型違反を表す400/500番台の異常系ステータスコード
APIが返すHTTPステータスコードと例外オブジェクトの返却
上記ステータスコードは、Interstage AR Processing Serverが返すコードです。以下のようなコードはInterstage AR Processing Serverではなく、WEBサーバ/JavaEE実行環境が返す場合があります。 「401 Unauthorized」等のHTTPの正常系ステータスコード。 HTTPメッセージフォーマット/パスフォーマット/JSONフォーマット/値型違反を表す400/500番台の異常系ステータスコード
REST APIの例外設計 - GeekFactory
REST APIを設計する場合に、エラーをどのステータスコードで返却するか議論になることがあります。例えば、以下のような場合が挙げられます。 キー指定のリクエストでDBにデータがない場合（例： GET /books/1 ） 一覧のリクエストでDBにデータがない場合（例： GET /books ） 必須項目がない、型が合わないといった場合（例： GET /books/find?count=bar ） ビジネスルールに違反する場合（例： POST /purchase ） 実行時エラー（例： NullPointerException ） クライアントが適切にエラーを処理できるように、レスポンスにエラー原因を入れることが一般的です。では、ステータスコードは何がいいのでしょうか。HTTPのステータスコードはRFCで定義されているし、RESTの考え方はWebや書籍にまとまっていますが、あくまでも考え方
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
そのリクエストパラメータ、クエリストリングに入れますか、それともボディに入れますか - Qiita
今回は、何らかのパラメータを扱うAPIを設計する際に、どこにパラメータを含めるべきかという問題について。 選択肢は3つあります。 1. クエリストリングに含める 2. リクエストボディに含める 3. パスに含める それぞれどんなユースケースに適しているのか例を挙げます。 1. クエリストリングに含める 何らかのリソースのフィルタリング、ソート、ページングを実現したいときに用います。 クエリ と名前がついているくらいですからね。 一覧や検索が主ですね。ゆえに GET 以外で見ることはほぼありません。 ただし、認証のような例外もあります。これは後述します。 検索
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
