app.get('/api/item/:id', (req, res) => { // ユーザー認証: AuthorizationヘッダーのJWTトークンを検証＆Subjectを特定 const subject = authenticateSubject(req.headers) // 権限チェック if (checkPermission(subject)) { ... // API固有の処理を実行 res.send(...) // CORS関連のレスポンスヘッダーをつけて返却 } else { res.send(403) // 権限がないことを通知 } }) app.post('/api/item/:id', (req, res) => { // ユーザー認証: AuthorizationヘッダーのJWTトークンを検証＆Subjectを特定 const subject = authent

200 Over API 接続のコンポーネントベンダーが語る！ 「APIのここがツライよ 15選」 #Burikaigi 2020 # Event Burikaigi 2020 https://toyama-eng.connpass.com/event/156635/ # Tool CData API Server https://www.cdata.com/jp/apiserver

更新APIの難しさ ネットワークの向こう側にあるリソースを更新するのは、単純なTCP/IPの仕組みでは難しい。その上に構成されたシンプルなプロトコルである単純なHTTPで実現しようとすると、以下に示すような箇所でエラーの発生可能性があり、双方で等しく検知することができないケースが存在し、同期的なリカバリが困難である。 エラーの発生箇所 1. クライアント→サーバの接続エラー 2. クライアントからリクエスト送信したがサーバに届かない。 3. サーバが不完全なメッセージを受信した。 4. メッセージがサーバの処理キューに入らない。 5. サーバで処理が正常に完了しない。 6. サーバからレスポンスを返そうとしたが接続が切れている。 7. サーバからレスポンスを返したが、クライアントに届かない table:エラー検知 クライアント サーバ ① コネクションタイムアウト,... 検知不能 ② ソ

https://fortee.jp/phpcon-2019/proposal/9fa39956-77db-4a1d-a5b9-db7bf608ae55

"RESTはxだからyを使おう"といった論調で，GraphQLやgRPC，非同期通信，あるいはそれらほど有名ではない選択肢を推奨する記事もあります。その主張は次のようなものです。 GraphQLはRESTより優れている。コンシューマが受信するデータをコントロール可能であり，APIプロバイダがリソースをサーバ側に集約できるからだ。 gRPC(とプロトコルバッファ)はRESTより優れている。タイプセーフで、バイナリシリアライゼーシfielding/pubs/dissertation/top.htm">Architectural Styles and the Design of Network-based Software Architectures"で定義されました。この論文の本当の目的は、"ソフトウェアアーキテクチャを理解するためのフレームワークの定義して ... ネットワークベースのアプリ

UIT#3 The “Backends for Frontends” sharing

API Meetupでこれまで発表され、公開可能な資料のリンクを纏めます。 API Meetup は Web APIに携わる開発・企画担当者が、APIまわりのさまざまな要素技術や適用事例を一緒に学ぶオープンなミートアップです。国内でのWeb APIの認知度を高め活用を促進すること、Web APIに関わる開発者のコミュニティを形成することを目的としています コミュニティページ 動画アーカイブ セッション資料一覧（公開可能なもの） 2014年 「Web APIのこれまでとこれから」リコー 山本陽平さん http://www.slideshare.net/yohei/webapi-36871915 「Twitter API最新事情」サムライズム 山本裕介さん http://www.slideshare.net/yusukey/api-meetup-tokyo-1 「クラウドサービスの Web A

presented at Go Conference 2018 Spring https://gocon.connpass.com/event/82515/ grapi: https://github.com/izumin5210/grapi grpc-gateway: https://github.com/grpc-ecosystem/grpc-gateway

会社のブログに書こうと思ったんだけど、ちょっとマイナスイメージを持つ人もいそうな気がしたので、個人ブログに書くことにした。 この3ヶ月くらい、システムのリニューアル(アプリ間で分散したロジックを集約するバックエンドサーバと、用途に応じたフロントエンドサーバを立てるみたいなマイクロサービス構成)をやっていて、そこでサーバ間のやりとりにgRPCを使っていた。すごーく雑な絵を書くとこんな感じです。 しかし、最近になってプロジェクトのスコープについて見直しが入りました。マイクロサービス化ではなく単純にレガシーJavaで独自FWなアプリをリプレースするだけになり、必要なのはSPAとSpringBootのAPIサーバだけに(要するにRails側のロジックをなんとかするのがスコープ外になった)。 で、SPAに提供するAPIのためにgRPC(+ grpc-gateway)を使うのはちょっとオーバースペック

こんにちは、LINEメッセンジャーのサーバーサイド開発チームに所属してスタンプや着せかえに関連する開発を担当している川田（@hktechno）です。この記事はLINE Advent Calendar 2017の2日目の記事です。 私が所属しているチームは、数年前からマイクロサービス化されたサービスのRPC（Remote Procedure Call）やDBアクセスを非同期化し、レイテンシの削減やサーバーリソースの省力化に勤しんできました。最近は、LINE内部で開発しているRPCサーバーArmeriaとRxJava 2を使って、“Javaにしては”なかなかイケている内部構成になってきました。この記事では、そんな私達のチームで開発しているスタンプ・着せかえ関連サーバーの裏側についてご紹介したいと思います。 LINE Shopにおけるマイクロサービス 一言でLINEといっても、LINEと名前のつ

この記事は 第2のドワンゴ Advent Calendar 2017 最終日の記事です。 はじめに ウェブ技術を語る上で欠かすことのできない要素として、HTTPがある。 従来のHTTP/1を無くして、ここまでのウェブの発展はなかったといえるだろう。言うまでもなく、HTTP/1が我々人類に齎した功績は大きい。 しかしその一方で、その規格のシンプルな原理原則に縛られた結果、要件を達成するために非効率なネットワーク使用を前提とするシステムが量産されるなど、HTTP/1がもたらした技術的負債も存在する。 その中の一分野として、双方向通信に着目したときに、HTTP/1からHTTP/2へのアップグレードによってどのような変化がもたらされたか。 本稿ではHTTP/2という規格と、それが持つ可能性の一端としてgRPCについての仕組みを紹介し、従来とこれからのWeb開発における双方向通信について述懐する。

Swaggerのテンプレートを魔改造した話 #渋谷java 1. Hidetake Iwata NTT DATA CORPORATION 第二十回 #渋谷java Swaggerのテンプレートを 魔改造した話 2. 2 3. Agenda 今日話すこと 1. 複数チームによるAPI開発の課題 2. What is OpenAPI? 3. サービス開発におけるOpenAPIの利用 今日話さないこと ● 大規模SI 3 4. 1. 複数チームによるAPI開発 4 5. 複数チームのAPI開発でよくある話（1/4） コンポーネントチームが並行開発を行う場合を考える。 5 フロント エンド サービスA サービスB フロントエンドチーム バックエンドチーム コンテンツプロバイダ 6. 複数チームのAPI開発でよくある話（2/4） 6 フロント エンド サービスA サービスB このAPI仕様で 提供

今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ

はじめに Web サービスの運用を続けていくと，依存関係が徐々に複雑になっていきます．そしてメンテナンスするものが増えた結果，それらが相互に乖離していく，といったことが起こりがちです． そこで今回は，JSON Schema のみをメンテナンスしていくことで，動的チェック (バリデーション)，静的チェック (FlowType)，API ドキュメント生成，スタブ作成といった様々な恩恵を享受し，品質と保守性を同時に向上させるアプローチについて書いていきます．この JSON Schema を中心に据えたエコシステムを，JSON Schema 中心設計と呼ぶことにします． JSON Schema の仕様については割愛しますので，必要な方は こちら をご覧下さい．また，本記事では JavaScript での事例を紹介しますが，他の言語でも同様の適用ができるかと思います． アプローチ 本記事では，以下の

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 -

前文 時々、このWeb APIってCSRF対策出来てますか？とか そのCSRF対策ってなんで安全なんですか？とか、そういう質問を友人・知人・同僚から受けます。 その質問に対して、都度回答をしているのですが、改めて記事としてまとめようかな、というのがこの記事です。 もし私の認識に穴・誤りがありましたら、ぜひ指摘お願いします。 前提事項 この記事中では、CSRF対策のみにフォーカスします。 そのため、以下はスコープ外です(無駄な議論回避のための前提事項です)。 セキュリティに銀の弾丸などないので、複数の脆弱性対策を組み合わせて、安全に行きましょう。 XSS脆弱性により、CSRFが可能である ブラウザの脆弱性により、CSRFが可能である XXXの脆弱性により、CSRFが可能である 前提知識 CSRF対策について語る上で必要な知識はいくつかありますが、この記事では以下の知識を前提に扱います。 ご存

PySpa統合思念体です。チャットで話をしたことのまとめです。何人かで雑に話をしたことのまとめで、特定の誰かの発言というわけではなく、一種の怪文書です。 さて、GraphQLが世間を賑わせ始めています。Facebookが開発し、GitHubも機能提供をし始めました。GraphQLはRESTの未来か？みたいな論調もありますが、新しいものが出てくると既存のものをサンドバックにして「まだそんな古いの使ってやがるのかよwwwww」みたいな煽りをするのはもはやウェブ界隈の風物詩になっていますが、そういう信者発言をして「ああ、あいつまた踊らされてるな」「あいつ技術を見る目がないな」みたいに思われないように、少し冷静にGraphQLの立ち位置や、今後予想される流れについて考えてみます。 LSUDsとSSKDs WebAPI The Good Partsでも紹介されていた概念として、Netflix社のAP

最近公開されたGitHubのAPIは、GraphQLという形式に対応しました。今後はこちらが主流になっていくようで、既存のREST APIからGraphQLへのマイグレーションガイドも提供されています。 今回は、このGraphQLについて、実際にGitHubのAPIを叩きながらその仕組みを解説していきたいと思います。 GraphQLとは 歴史 GraphQLは、Facebookの中で2012年ごろから使われ始めたそうです。その後2015年のReact.js Confで紹介されたところ話題となり、同年"technical preview"のステータスでオープンソースとして公開されました。その後仕様が詰められ、2016年9月に晴れて"preview"を脱し公式実装として公開されました。これと同じタイミングで、GitHubからGraphQLバージョンのAPIが公開されています。 このあたりの経緯