GoogleのWebAPI設計とWebAPI設計のベストプラクティスを比較してみる
RESTful な URL にしよう 元記事 GET /tickets - チケットのリストを取得する GET /tickets/12 - 指定したチケットの情報を取得する POST /tickets - 新しいチケットを作成する PUT /tickets/12 - チケット #12 を更新する PATCH /tickets/12 - チケット #12 を部分的に更新する DELETE /tickets/12 - チケット #12 を削除する Google GET /events - 予定のリストを取得する GET /events/12 - 指定した予定の情報を取得する POST /events - 新しい予定を作成する PUT /events/12 - 予定 #12 を更新する PATCH /events/12 - 予定 #12 を部分的に更新する DELETE /events/12 -
Kong を使った Microservices Architecture API Gateway Pattern の実現方法 - Qiita
Kong を使った Microservices Architecture API Gateway Pattern の実現方法Dockermicroservices この記事は、Kong - API Gateway Pattern速習会＠Wantedlyの資料として作られたものです。 サービスが大きくなるとやりたくなってくること より高速な実装に置き換えたい APIを複数のサービスに分けて開発したい マイクロサービス化 何故マイクロサービスか James Lewis/Martin Fowlerの"Microservices"日本語訳 State of the Art in Microservices by Adrian Cockcroft - Qiita いろいろ理由は言われてるけど... 人が扱える大きさの限界 「明確な」境界が必要 名前空間やスコープなど、プログラミング言語でも使用してい
KONGことはじめ - Qiita
KONGとは 公式読めってのはおいといて 噛み砕いて説明すると マイクロサービスを構築する時のAPI Gatewayとなるもの リバプロの役割をしてリクエストを各APIに振り分けるよ pluginで認証や流量制限、ログ取りもできるよ kong本体もクラスタ化できるし、APIもアグリゲーションできるよ API GatewayみたいのがないとたくさんAPIサービス作るとわけわかんなくなっちゃうよ 実際はnginxの拡張モジュールのようなものでAPIを経由してnginxの設定に反映してくれる感じ つまり色々な言語で実装されたAPIサービスの総合窓口。 KONG配下にAPIサービス群を置いてあとはfrontendでもcurlでも好きに叩けば？ くらいの構成にできそう KONG以外だとcloud系でAWS API GatewayとかAzureのAPI ManagementとかGoogle Cloud
翻訳: 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ページを開く
API Blueprintでアクション毎にURI parameterを定義する
