API Meetup Tokyo #15 〜OpenAPI Specification (Swagger)特集〜 2016-07-22（金）19:00 - 21:00 API公開に向けたパイロットPJにて、設計、実装（単項目チェック）、ドキュメント、仕様公開にSwaggerを採用した際の経験談をお話します。Read less

Inside FrontEndに引き続き、ブログ書く枠で参加させて頂きました。 今回で5回目となるMicroservice meetupですが、中々都合がつかず、 個人としては今回が初めての参加になります。 microservices-meetup.connpass.com 目次 目次 発表項目 step by step BFF 1 BFFとは 2 BFFが担う役割 1 API Aggregation 2 Session Management 3 (Server Side) Rendering 4 File Upload 5 WebSocket / LongPolling / SSE(Server Sent Events) Cache 3 BFFが生まれた背景 4 BFFの利用事例(Twitter,Netflix,RecruitTech) 1 Twitter 2 Netflix 3 Rec

大規模なサービスのAPIを開発する際に、ルールを決めずに開発していると無秩序なコードが散見される運用がしづらいAPIになってしまいます。また、ルールを決めたとしても共有が上手くいかないなどの理由で守られなくなってしまうこともあると思います。 本記事では、APIを運用しやすくするために、ただルールを決定しただけではなく、ルールを守るためにそれぞれ仕組み化をしたことを紹介します。 APIのレスポンスを統一する デコレーターを使ってレスポンスの定義を綺麗に書く パラメーターを統一する Validatorによりパラメーターの明記を強制する コーディング規約を守る LinterとSideCIを導入して修正とレビューの自動化 Linterのルールを適度に調節する 1. APIのレスポンスを統一する ここで言うAPIのレスポンスを統一するというのは、返すAPIフォーマットのブレをなくすことです。フォーマ

タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy（同一生成元ポリシー）によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので（自分的）これが決定版！　という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio

Networks are unreliable. We’ve all experienced trouble connecting to Wi-Fi, or had a phone call drop on us abruptly. The networks connecting our servers are, on average, more reliable than consumer-level last miles like cellular or home ISPs, but given enough information moving across the wire, they’re still going to fail in exotic ways. Outages, routing problems, and other intermittent failures m

Send feedback API design guide Stay organized with collections Save and categorize content based on your preferences. Changelog Introduction This is a general design guide for networked APIs. It has been used inside Google since 2014 and is the guide that Google follows when designing Cloud APIs and other Google APIs. This design guide is shared here to inform outside developers and to make it eas

Webアプリケーションの認証トークン（セッション）はCookieヘッダで送信するのが一般的だとは思いますが、 そろそろこのCookieに依存した方法は負の遺産ではないでしょうか？ 認証トークンの送信はRFC 7235で規定されているAuthorizationヘッダを使うと良いです。Basic認証とかDigest認証で使うやつですね。 実はBasicやDigestの他にRFC 6750でBearerというスキームが登録されています。単一の文字列を認証情報として送信するためのスキームで、トークンを送信するのにピッタリです。 参考: トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた その場合は、認証トークンはCookieではなくlocalStrage（またはsessionStorage）に保存することになると思います。

マイクロサービスアーキテクチャが話題を集め、コンポーネントのWeb API化が更なる急加速を見せる昨今。 とは言え「誰でも自由に叩いて良い」Web APIなんてのは事実上無く、ほぼ全てのケースで何かしらのアクセス制御が必要になります。 - Spring Security もサポートする昔ながらの「Basic認証」。古い、ということは、悪いソリューションなのか？ - 最近のAPIのアクセス制御と言えば「OAuth 2.0」がトレンディ？ Spring Security OAuth もあるし！ - 一方でAWSは「APIキー方式」を採用。なぜAWSはOAuth2ではないのか？ - Spring Security はまだ公式にサポートしていない「OpenID Connect」とは一体…？ Webにおけるアクセス制御の歴史を振り返りつつ、様々なAPIの立ち位置と共に、その最適解を探っていきたいと思

2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの

背景 最近は変化し続ける要件に対応するために、システムも柔軟であることが求められています。 そのため、部分的に変更やスケールの可能なシステムを構築し、API経由で連携するマイクロサービス的アーキテクチャが増えてきています。 そういった設計の中で問題になっていくのが、従来のモノリシックなアプリケーションではIDEやコンパイラなどで行っていた、機能間のインターフェイスをどう管理するかという部分です。 Swaggerとは? SwaggerとはRESTful APIのドキュメントや、サーバ、クライアントコード、エディタ、またそれらを扱うための仕様などを提供するフレームワークです。 公式サイトでは、The World's Most Popular Framework for APIsと謳っています。 その理由は、マイクロソフト、Google、IBM、SmartBearなどを大手の企業を含む「Open

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

充実したAPIとサポート環境で開発コストを削減 「駅すぱあと」が持つ全国の公共交通データと、多くの法人向けサービスや基幹システムに 採用されている信頼性の高いAPI。 公共交通に特化し、多くの開発者に支持される豊富な機能をご覧ください。 90日無料評価版で試す APIドキュメントをみる 公共交通機関の検索に特化した充実のAPI 乗換案内・定期代検索・定期代の払戻計算、鉄道・バス・航空・船の情報など、公共交通機関の検索に特化したAPIによりニーズにあわせたサービスが実現できます。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は下記のURLにあるコミックマーケット90で頒布した同人誌と自分が管理するブログの記事を微修正し、転載したものです。 南関東開発機構 : 同人誌「日本の行政機関が公開中のAPIについて調べてみた本」を公開しました http://blog.livedoor.jp/south_kanto_dm/archives/52143201.html 南関東開発機構 : 日本の行政機関が公開中のAPIについてのまとめ（2016年8月17日暫定版） http://blog.livedoor.jp/south_kanto_dm/archives/5

厳格な定義はないが、広義にはHTTPプロトコルを用いてネットワーク越しに呼び出すアプリケーション間、システム間のインターフェースのこと。 APIの機能はわかっているけれども、その中身の実際の動作は詳しくわからない(知らなくてもよい)機能の塊を、外部から呼び出す仕様のことを指す。また、上記図の右側の「呼ばれる側のシステム」そのものをWeb APIと呼ぶこともある。 ※APIとはApplication Programming Interfaceの略。 Web APIの重要性 Web APIの重要性は年々高まっている。 ※以下の図はオージス総研グループのもの Web APIの歴史 古くから知られており非常に普及したWeb APIとして、2003年に公開されたAmazonのProduct Advertising APIがある。 ※ちなみに、当時はAWS(Amazon Web Service)という

Wantedlyは、運命のチームや仕事に出会えたり、人脈を広げ、ビジネスの情報収集に使えるビジネスSNSです。

Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。 マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。 「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか? Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。 いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。 マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編) ECサイトをマイクロサービスアーキテクチャで作ることを考えてみ

技術部の taiki45 です。 以前「サービス分割時の複雑性に対処する: テスト戦略の話」という記事で、サービス間のインテグレーションテストにおける問題について紹介しました。現在のクックパッドではこの問題の解決のために Pact というツールを導入して運用しています。この記事では、その運用の知見を紹介できればと思います。 Pact Pact は Consumer-Driven Contract testing (CDC testing) を実現するためのツールです。"Consumer"、"Provider" という見慣れない単語が出てきますが、この記事ではだいたい「Consumer = Web API クライアント」、「Provider = Web API サーバー」と対応ができます。この記事では具体的な Pact の利用例を通じて CDC testing がどういうものなのかについても