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を設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
Book: Web API: The Good Parts - @kyanny's blog
内容はよくまとまっていた。確かにそこは悩むよね、という点がいくつもカバーされていて、かつ既存の API をリサーチしたまとめを元にベターな選択肢が述べられていて納得感がある。 API の設計や実装に慣れている人でも、迷ったときのリファレンスとして利用できると思う。薄い本なので全体的に言及が浅い印象があるけど、随所でより深い議論へのポインタがあるのもよい（海外ブログの URL とか） セキュリティの話題を扱う第6章だけ異彩を放っている感じがした。一読する価値はあるけど、バージョニングの話とかレスポンスデータ構造の話とかと比べるとだいぶ毛色が違っていて、この章の一部だけ妙に収まりが悪く感じた。 校正が杜撰だった。あまりにひどくて読みながら誤変換とかミスっぽい部分をメモしたら21箇所もあった。それ以外にも日本語の文章としてなんか変、みたいなのもあった。今まで読んだ本のなかで最低レベルのミスの多さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
