オープンソースのAPI Gateway「Kong」
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） 全国100万人のモノリシック巨大アプリケーションに苦しむみなさんこんにちは。 世の中猫も杓子もマイクロサービスだ!!とかAPIだ!!とか言っていますが、実際にマイクロサービス環境にしようとすると、どのようにしてAPIのサービスを取りまとめるかが課題になります。 一般的には以下のようなやり方になります。 複数のサービスに分散しているAPIを統合するゲートウェイを用意するそのゲートウェイでは以下のようなことをおこなうクライアントからのアクセスのシングルエンドポイントの役目を果たすAPIの実体へのルーティング認証アクセス記録の収集スロットリング(過度なアクセスの抑止)実体がダウンしている場合のデグレーションこのようなAP
『[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)
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 アプリの設計レビューの話
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSON Schema で Web API のスキマを埋めよう
WEB APIのURL設計のトレンドはこれだ！WEB APIのURL設計まとめ
Amazon.co.jp: APIデザインの極意 Java/NetBeansアーキテクト探究ノート: Jaroslav Tulach (著), 柴田芳樹 (翻訳): 本