オープンソースのAPI Gateway「Kong」
全国100万人のモノリシック巨大アプリケーションに苦しむみなさんこんにちは。 世の中猫も杓子もマイクロサービスだ!!とかAPIだ!!とか言っていますが、実際にマイクロサービス環境にしようとすると、どのようにしてAPIのサービスを取りまとめるかが課題になります。 一般的には以下のようなやり方になります。 複数のサービスに分散しているAPIを統合するゲートウェイを用意するそのゲートウェイでは以下のようなことをおこなうクライアントからのアクセスのシングルエンドポイントの役目を果たすAPIの実体へのルーティング認証アクセス記録の収集スロットリング(過度なアクセスの抑止)実体がダウンしている場合のデグレーションこのようなAPIゲートウェイの機能は既にAWSではAmazon API Gatewayとして提供されていますが、オープンソースでもいくつかのプロダクトがあります。今回はそのうち一番開発が活発そ
『[node.js]asyncを使って非同期処理を制御2』
asyncを使って非同期処理を制御2前回の続きです。前回は非同期のtaskを順次または平行に処理を行う方法を書きましたが、今回は配列に特化した関数を紹介しようと思います。前回の記事の内容は理解していることを前提に書きます。 基礎編 配列の順次処理と並行処理今回はasync.each, async.eachLimit, async.eachSeries, async.map, async.mapLimit, async.mapSeriesの6つを説明したいと思います。6つもありますが関数名で察しがつく通り、覚えることは3つぐらいです。eachとmapの違いはArray.forEachかArray.mapかぐらいの違いです。~Seriesがあると無いとの違いは順次処理か並行処理かの違いです。~Limitもそこまで難しいことはないです。 async.each(arr, iterator, cal
![『[node.js]asyncを使って非同期処理を制御2』](https://cdn-ak-scissors.b.st-hatena.com/image/square/83d61cd81373359353905d64d3800fef4d2f750e/height=288;version=1;width=512/https%3A%2F%2Fstat.profile.ameba.jp%2Fprofile_images%2F20141009%2F17%2Ffe%2FuF%2Fg%2Fo014001401412842872585.gif)
JSON Schema で Web API のスキマを埋めよう
クライアント実装 サーバ実装 仕様 Web API にありがちなこと API ドキュメント リクエスト レスポンス ぶっちゃけAPI の追加時く らいしか更新していない なぜかドキュメントにない属性が 含まれている 手が滑ってドキュメントと若干違う形式の 属性を含めちゃったけどなんとなく通った クライアント実装 サーバ実装 仕様 いまは API Blueprint で頑張ってる (http://apiblueprint.org/) API ドキュメント リクエスト レスポンス Markdown の スーパーセット (ツラい) API Blueprint (YAML 表現) generate mock validate あんまり嬉しく ない なんか別に JSON Schema 書かない といけない クライアント実装 サーバ実装 仕様 今日話したいこと JSON Schema API ドキ
Gradle User Guide
Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically. このドキュメントは、個人利用目的および第三者に配布するためにコピーして使用できます。ただし、印刷するにせよ電子媒体を使用するにせよ、以下の点に留意してください。どのような形態であれ使用料を課さないこと。また、このコピーライト条項を配布物に含めること。 例目次 6.1. 初めてのビルドス
RESTful Zip Search API Specification -- ricollab
このサービスで提供するリソースは、以下の3種類の表現を持ちます。 XHTML Media Type: application/xhtml+xml; charset=utf-8 標準的な Web ブラウザで表示することのできる形式です。ブラウザで表示させることが可能なので、人間が読みやすいのが特徴です。この表現は整形式の XML であるため、XML パーサーでパースして、プログラムから扱うことも可能です。住所の構造情報は class 属性で表現されています。全てのリソースのデフォルト表現になっています。 この表現は妥当な XHTML 1.1 になるはずですが、あえて DOCTYPE 宣言は付けていません。文字エンコーディングスキームは UTF-8 です。 http://zip.ricollab.jp/1120002 http://zip.ricollab.jp/search?q=大手町 ht
URL Design — Warpspire
December 28, 2010 URL Design You should take time to design your URL structure. If there’s one thing I hope you remember after reading this article it’s to take time to design your URL structure. Don’t leave it up to your framework. Don’t leave it up to chance. Think about it and craft an experience. URL Design is a complex subject. I can’t say there are any “right” solutions — it’s much like the
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
RESTful Web アプリの設計レビューの話
1. RESTful Web アプリの 設計レビューの話 和田 卓人 (a.k.a id:t-wada or @t_wada) July 23, 2012 @ sendagaya.rb 3. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ･クエスト株式会社 取締役社長 4. 私と REST (input) • WEB+DB PRESS vol.32「REST アーキテクチャスタイル入門」 • はてぶ設計議論 • DHH の RubyKaigi 2006 Keynote • WEB+DB PRESS vol.38∼「REST レシピ」 • 『RESTful Web Service』
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WEB APIのURL設計のトレンドはこれだ！WEB APIのURL設計まとめ
Amazon.co.jp: APIデザインの極意 Java/NetBeansアーキテクト探究ノート: Jaroslav Tulach (著), 柴田芳樹 (翻訳): 本