この記事は、Kong - API Gateway Pattern速習会@Wantedlyの資料として作られたものです。 サービスが大きくなるとやりたくなってくること より高速な実装に置き換えたい APIを複数のサービスに分けて開発したい マイクロサービス化 何故マイクロサービスか James Lewis/Martin Fowlerの"Microservices"日本語訳 State of the Art in Microservices by Adrian Cockcroft - Qiita いろいろ理由は言われてるけど... 人が扱える大きさの限界 「明確な」境界が必要 名前空間やスコープなど、プログラミング言語でも使用している 一段上の概念だと思うと良い 大きいメソッドが管理できないのと同様に、大きいサービスも管理できない 組織体系に影響を与える 100人のチームで開発するのが嫌ならや
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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く