変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gRPC API を中心に、REST API と RPC API の両方に適用されます。gRPC API では、プロトコル バッ
REST APIを設計する場合に、エラーをどのステータスコードで返却するか議論になることがあります。例えば、以下のような場合が挙げられます。 キー指定のリクエストでDBにデータがない場合（例： GET /books/1 ） 一覧のリクエストでDBにデータがない場合（例： GET /books ） 必須項目がない、型が合わないといった場合（例： GET /books/find?count=bar ） ビジネスルールに違反する場合（例： POST /purchase ） 実行時エラー（例： NullPointerException ） クライアントが適切にエラーを処理できるように、レスポンスにエラー原因を入れることが一般的です。では、ステータスコードは何がいいのでしょうか。HTTPのステータスコードはRFCで定義されているし、RESTの考え方はWebや書籍にまとまっていますが、あくまでも考え方
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
