httpbin.orgA simple HTTP Request & Response Service. Run locally: $ docker run -p 80:80 kennethreitz/httpbin
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
HTTPの間違いやすい点: akiのお部屋
Web開発者はHTTPについて知らない（Webを理解してないWebアプリ開発者）ということを書いたんですが、HTTPを簡単に言ってしまうと、リソースに対するCRUDについての取り決め（プロトコル）です。本来はW3CのRFCを読むのが良いんですが、以下のサイトが非常によくまとまっていて読みやすいです。 Studying HTTP で、HTTPの細かいところの言及は避けるとして、aki的には、このHTTPを利用するときに間違えやすい点をまとめていこうと思います。 ①リソースにURIを割り当てていない リソースというのはURI（Uniform Resource Identifier）というIDで一意に識別されます。 1つのURIに複数の意味を持たせ、渡すパラメータ（クエリーストリングなど）でリソースを識別しようとすることです。 例えば、こんな感じ /resources?type=entity&i
yohei-y:weblog: HTTP ステータスコードを正しく使おう
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
json-head
