5歳娘「パパ、変なAPIを作らないで？」 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? とある休日 娘（5歳）「パパ、一緒に技術ブログを始めない？」 娘「昔から私とパパがローカルに書き溜めてる技術記事が、かなり溜まってきたでしょ？」 娘「それをブログとして公開してみようよ」 ワイ「おお、それは楽しそうやな」 ワイ「どこのブログサービスを使おうかいな」 娘「せっかくなら、ブログシステムから自分たちで作ってみようよ」 娘「私はフロントエンドを担当するから」 娘「パパはRuby on Railsか何かで、APIを作ってよ」 ワイ「おお、Ruby on Railsなら昔やったことあるわ」 ワイ「RailsのAPIモードで、ブログ記
メルカリShops 注文システム反省会 | メルカリエンジニアリング
こんにちは。ソウゾウ Software Engineer の @sou です。連載：メルカリShops 開発の裏側 Vol.2 の6日目を担当させていただきます。 この記事ではメルカリShops 注文システム反省会として、リリースから半年を迎える中で注文システムにどのような問題が起こり、どのような改修が必要になったかを振り返ってみたいと思います。 注文システムの概要 メルカリShops はマイクロサービスで構成されており、注文の受付を行うために様々なマイクロサービスにまたがって API を呼び出す必要があります。 まずは購入画面をご覧ください。 メルカリShops の購入画面 「購入する」を押すとローディングアイコンが表示されて待ちに入り、クライアントがレスポンスを受け取ると購入の完了を示す画面が表示されます。 一方裏では購入を完了させるまでに在庫確保や決済など様々な操作を行っています。
Web API の CSRF 対策まとめ【追記あり】 - Qiita
セキュリティ脆弱性診断などでたまに CSRF について指摘されることがあります。 今まではトークン発行して対応すれば良いんでしょ？ と思ってましたが、SPA のように非同期通信が前提の場合はどう対処するべきなんだろう、と疑問が出たりしたので、調べてみた結果をまとめてみました。 CSRFとは Cross Site Request Forgeries（クロスサイトリクエストフォージェリ）の略で、 サービス利用者の正規権限を利用して、意図しないタイミングでサービスの機能を実行させる攻撃手法のことを指します。 2005年に mixi 日記で発生した「ぼくはまちちゃん」で一躍有名になりました。 大量の「はまちちゃん」を生み出したCSRFの脆弱性とは？ - ITmedia エンタープライズ CSRF が発生する原因 サービスの機能を実行するプログラムへのリクエストの検証が権限情報のみであった場合に発生
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外ではCSRFを考慮しなくてよい、 という前提で話を進めます。 また、XSSに関しては常に対策は必要なのですが（フレームワーク側が自動的にしてくれる部分もある）、認証周りに関係すること以
GraphQLでバックエンドのコードをすっきりさせた話 - LayerX エンジニアブログ
こんにちは！LayerXの mosa_siru (榎本) です。 LayerX インボイスでは、もともと github.com/go-swagger/go-swagger を利用してREST APIを開発していましたが、最近開発したワークフロー機能 のコンポーネントではGraphQLを取り入れました。 GraphQLには様々なメリットがあり、RESTとの比較記事は多くありますが、なぜ僕らは移行したのか、その結果どうなったのかを紹介していきます。 GraphQLのメリット GraphQLのメリットは、様々な箇所で語られています。例えばこの記事によれば、 強力に型付けされたスキーマであること アンダーフェッチとオーバーフェッチがないこと（後述） Apollo, Relayなどの、クライアントライブラリにより、フロントエンド開発が迅速になること 複数のGraphQL APIからの統合が可能 強力
クエリストリングで配列を表現をするケースをざっと調べる - コード日進月歩
これどこだと通用するの？と思ったので軽く調べる TL;DR PHPが言語デフォルトで相互変換でき、Railsだとそれに親しいことができる機能がある。 対象とする表記 下記のようなクエリストリング http://example.com/home?values%5B0%5D=zero&values%5B1%5D=one&values%5B2%5D=two URIエンコードしてるから見づらいが、デコードするとこんなクエリ values[0]=zero&values[1]=one&values[2]=two 添字を指定して配列っぽい記述だけど、配列？みたいな記述 そもそもクエリストリングの仕様に配列の言及があるのか そもそもとして ? 以降のフォーマットに関してどういう値設計にするかのルールは特に記述されていない しかし、query 構成要素はしばしば "key=value" の対の形式で識別する
GraphQL APIをスキーマファースト開発するためのモックサーバをRailsとApolloで作る
GMOペパボ Advent Calendar 2017の23日目の記事です。 今回はJavaScriptでGraphQLのサーバ／クライアントや関連ツールを提供しているApolloのツールセットでRailsプロジェクトでGraphQLのモックサーバを立ち上げるところまでを試してみます。 業務でRails製の（RESTishな）Web APIとVue.js製のSPAからなるアプリケーションを開発していて、スキーマファースト開発を取り入れています。また、GraphQLで通信するAPIを実験的に導入しはじめていますが、こちらは明示的な開発フローを決めず導入しようとしているため、なかなかサクサクと開発が進まないのが現状です。そこで、GraphQLでも先にインタフェースだけを決めてから、モックサーバを使ってフロントエンドとバックエンドで並行開発していけばよいのでは、という発想になります。 しかし、そ
GraphQLとPersisted Query - Qiita
最近、GraphQL APIをインターネット上に晒す上で何を考慮したらいいのだろうか、的なことを考える機会が多く、空いた時間でチマチマと素振りしています。 今日はGraphQLのクライアント - サーバー間に挟むリバプロ的な機能について書いてみようと思います。 やりたいこと 1. 想定しないクエリの排除 例えばECやメディアサイトのような、未ログインでも情報の閲覧が可能なサービスのWeb API層をGrahpQLで実装したとします。ECにしろメディアにしろ、詳細ページでの回遊率を上げるため、詳細同士を関連付けるようなスキーマ設計となるのは自然なことでしょう。 GrahpQLのスキーマ定義で書くと、下記のようなイメージです。
技術系の境界線 | La Verda Luno
これは 設計ナイト2020 の感想記事です。 CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話（触ってみたレベルでなく実運用等を経たもの）についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ
gRPCとGraphQL - Qiita
はじめに gRPCとGraphQLをどう使い分けるかがわからず混乱していたので、軽く整理した。 どう違うか GraphQLはAPI用のクエリ言語で必要なデータを指定することで無駄な通信をしないようにすることができる。 一方でgRPCはProtocol bufferを用いてRPC(サーバー上のメソッドをあたかもクライアント側で呼んでいるかのように見せるもの)を実現している。 どちらも、サーバーに対してリクエストを出しレスポンスを受け取るという目的は一緒。 ただ、gRPCはGraphqlのように柔軟なクエリ（関数呼び出し）はない。 サービスという形でRPCの関数を呼び出し結果を得るが、その結果の形は固定。 また、Mediumの記事でも述べられている通り、gRPCは低レベル向き、GraphQLは高レベル向き。 なので、ウェブアプリを作るときには、フロント側がアクセスするAPIはGraphQLで、
RESTful API のページネーションで考えるべきこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※追記：パフォーマンス比較ですが、「インデックスちゃんとはったら良くね？」との指摘がありました。その通りです。申し訳ありません。 RESTful な API を作る時のページネーションのプラクティスが Django RESTful Framework の Pagination に良くまとまっているので、 Django 以外の別の実装のためにも汎用化したい。 レスポンスの表現方法 レスポンスで次のページを示す方法には以下の方法がある。 JSON や XML のレスポンスに含める Link ヘッダに URL で指定する RFC 8288 G
JSON Schemaについて発表しました
「JSON Schemaでバックエンドエンジニアとフロントエンドエンジニアがコラボする」と題してエムスリー x Gunosy Beer bashで発表してきました。 当日ハッシュタグ: #gunosybeer hashtag on Twitter 発表資料2 Types of JSON SchemaJSON Schema and Hyper-Schema JSON SchemaJSON Hyper-Schema JSON SchemaJSONの データフォーマット を記述する人間にも機械にもわかりやすいドキュメントフォームでサブミットするデータのバリデーションに使える自動テストにも使えるJSON Hyper-SchemaWeb APIの仕様 を記述するAPIで期待するデータをJSON Schemaの形式で記述日本ではこっちの方がポピュラー？観測範囲内だと日本のコミュニティでJSON Sch
go-swagger を使って swagger から Goのサーバとクライアントのコードを生成する - Qiita
swaggerの定義ファイルからgo-swaggerを使ってGoで書かれたサーバとクライアントのコードを生成して,実際にAPIを叩いてみようと思います 公式ドキュメントはこちら swagger とは swagger とは RESTful API の仕様を定義したオープンソースのフレームワークです マイクロソフト, Google, IBM などが参加する 「OPEN API Initiative」 という団体が The Linux Foundation の協力のもと推進しています サーバ, クライアントのコード以外にもテストやドキュメントの生成もすることができます インストール install from source
新Instagram Graph APIを使ってインスタグラムの画像をWebサイトに表示させる
Instagramでは、2020年までにInstagram APIを使って行える機能のすべてを段階的に停止していくみたいです。 停止されると言われている機能としては、位置情報を利用した特定エリア内の写真検索、タグ情報やタグに紐づいた最新メディアの取得、タグの検索。ロケーション情報やロケーションに紐づいた最新メディアの取得、位置情報によるロケーション検索などです。最終的には自分のInstagramの写真を自分のWebサイトに表示させることもできなくなるみたいです。 そこでInstagram APIからInstagram Graph APIへ移行して、自分のWebサイトにインスタグラムの画像を表示させる方法を、ご紹介したいと思います。 Instagram APIからInstagram Graph APIへ移行 FacebookページとInstagramビジネスアカウントを連携させる Faceb
API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。 ほとんどのソフトウェア デベロッパーがご存じだと思いますが、API 設計には RPC と REST の 2 つの主要なモデルがあります。モデルに関係なく、ほとんどのモダン API は、なんらかの方法で同じ HTTP プロトコルにマッピングすることによって実装されます。また、RPC API 設計では、RPC モデルの範囲から外れずに HTTP から 1 つまたは 2 つのアイデアを採用することが一般的になっています。これにより、API 設計者に提示されるオプションの範囲が広がりました。この投稿ではこれらのオプションについて説明し、どれを選ぶか決める際に役立つガイダンスを提供します。 gRPC は RPC API を実装するためのテクノロジーで、HTTP 2.0 をその基盤
無料天気予報APIのOpenWeatherMapを使ってみる - Qiita
はじめに プログラムから天気予報をとるために、無料で開発者用APIを提供しているOpenWeatherMapを使ってみました。 概要 OpenWeatherMapはAPIだけのサービスというわけではなくGUIでも天気を取得できます。トップページにデカデカ「Current weather and forecasts in your city」と書いてあり、地名を入れると天気予報を表示してくれます。 これは普通に便利ですね とは言いつつもメインはAPIみたいです。APIを使うには登録してAPI Keyを取得する必要があります。 値段 無料プランを始めとして、いくつかプランがあります。 無料のFreeプランだと5日後までの3時間毎の天気予報を取得できて、1分間に60回までAPIコールできます。月180ドルのDeveloperプランでは3000 calls/分までOKで、16日後までの天気予報を取
Go言語でAPIクライアントライブラリを実装する - Qiita
概要 あるサービスを使った開発をするとき、そのサービスが提供しているAPIを使いますよね。例えば、githubのissuesを監視するサービスを作りたいとすると、何らかの形で githubレポジトリのissues一覧を取得するAPI を利用しそうです。当然ですが、このようなAPIはcurlで叩くことができます。例えばrailsのissues一覧を取りたければ、以下のコマンドを打てばOKですね。 とは言っても、実際にAPI使った開発をするときは、外部コマンドとしてcurlを使うのではなく、開発に用いている言語のAPIクライアントライブラリを使うでしょう。例えば、上記のgithubのissuesを監視するサービスをgoで開発するならば、goのgithubクライアントライブラリ を使うことになると思います。きちんと作られたクライアントライブラリを使うことで、APIリクエストの組み立て・APIレス
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GraphQLがRESTに取って代わるということはありえますか？
GitHub - APIs-guru/graphql-apis: 📜 A collective list of public GraphQL APIs
