悪いWeb API設計
[1] Web API (HTTP による API) の悪い設計例やどう設計するべきかの指針のご紹介です。 [138] 何が良いかは諸説あり宗教的で難しいですが、 悪いものには悪い理由があるので賛否はともかく参考になるはずです。 バージョニング (版付け)[2] API にバージョンを設けるべきではありません。 API の拡張は、常に後方互換性を保った形で行うべきです。 [3] 従って URL や HTTPヘッダーなどにバージョン番号を指定させる必要はありません。 [7] やむを得ず非互換変更せざるを得なくなった時は、非互換な機能のみ、 新しいエンドポイントを設けるべきです。はじめから非互換変更するつもりで準備しておくのは無駄ですし、 非互換変更するための言い訳を用意するようなもので、危険です。 [38] バージョンが複数あるということは、同じものを複数メンテナンスし続けなければならないと
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
