サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
この記事はSmartHR Advent Calendar 2020 11日目の記事です。 僕のお手伝いしているSmartHRでは、毎週バックエンドエンジニアが集まり、技術的なトピックについて共有、相談しあうミーティングを開催しています。そのミーティングでは僕がTipsなどを共有するコーナーが常設されています*1。 このエントリでは、そのコーナーで共有した内容をひとつ紹介します。APIに制限をかける方法についてAPIを外部に提供するとき、一定の制限をかけてユーザがAPIを乱用するのを防ぐことはよくあることではないでしょうか。素直に考えると「1時間に5000回までAPIを実行できる」のようなやり方を思いつきますね。GitHubのAPIもそのやり方ですし、SmartHRのAPIも同様です。 じゃあそれでいいのでは。となるかもしれませんが少し待ってください。いろんなクライアントがAPIを大量に
RESTfulAPI のおさらい 前後リンク RESTfulAPI のおさらいRails での JSONAPI 実装まとめ スキーマファースト開発 The NEXT of REST REST の歴史 REST (REpresentational State Transfer) という言葉は 2000 年に Roy Fielding の博士論文で初出しました。 (思想としてはその前からあった？ REST 入門) 日本では 2005 年ぐらいから徐々に流行りだして、 2006 年に WEB+DB Press で特集や連載が組まれる等が行われ、 (Rails 2.x が RESTful を打ち出した) 2007 年の終わりには web 開発者の間では一般化した言葉になっていたって印象。 なぜ REST が必要になったのか はるか昔はメインフレーム上で全部入りのアプリケーションを開発してい
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTPAPIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTPAPIs HTTPAPIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はRESTAPIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWebAPIで通信するケースも増えてきているように思います。APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
id:gfxです。 RejectKaigi 2017で「GraphQL onRails」という発表をしました。 当日はKibelaでプレゼンテーションをしたので、それをそのまま資料として発表します。 2017/08/19 at Speee, Roppongi. 自己紹介 Kibelaという情報共有サービスを開発している Kibelaの公開WebAPIをフルスクラッチするにあたってGraphQLを調べているところ 自分のOSSを誰かに引き継いだり共同開発体制にしていたら、GitHubのpinned reposがすべてorganizationのものになった本日の話GraphQLとはGraphQLをRailsに組み込む話GraphQLとは WebAPI のためのクエリ言語 http://graphql.org/ RESTfulAPI の次を狙うWebAPIアーキテクチャという位
Whenit comes toAPIs, change isn’t popular. While software developers are used toiterating quickly and often,API developers lose that flexibility as soon as even one user starts consuming their interface. Many of us are familiar with how the Unix operating system evolved. In 1994, The Unix-Haters Handbook was published containing a long list of missives about the software—everything from overly
で完了 なければ nodeのバージョンをnで管理する などを読みつつnodeとnpmをインストールしてください 準備するもの コンソールdb.json ブラウザ（動作確認用） やることdb.json ファイルを作成する bashの touch コマンドやWindowsなら右クリックからなどでお好きなようにファイルを作ってくださいdb.json にリソースを登録する ここでモックサーバから返して欲しいデータリストを列挙します 最上位の階層の key がエンドポイントになります { "users": [ {"id": 1, "name": "hoge"}, {"id": 2, "name": "fuga"} ], "tweets": [ {"id": 1, "contents": "あー眠い", "user-id": 1}, {"id": 2, "contents": "ファビュラス！"
技術開発本部の qsona です。 先日、 ぎんざRuby会議01 というミートアップが開かれました。これは、弊社の技術顧問のwillnetさんを含む3人の方によって運営されている Ginza.rb というコミュニティの50回目を記念して開かれたものです。 このミートアップにCFPを投稿し、採択いただきました。かなりの高倍率の中、目にとどめていただけたこと、また普段お世話になっているコミュニティの節目の会での発表の機会を頂けるということで、非常に有り難いことでした。 発表資料以下がその発表資料です。また、引用した文献をこの下に列挙したので、適宜ご参照ください。 引用文献p3 マイクロサービス時代に捧ぐ、Railsでの中規模APIサーバ開発のための技術構成 — qsona (Qiita) p27 step-by-step BFF — Yosuke Furukawa (Speaker Deck
概要 スマホアプリ時代のAPI戦略としてオーケストレーションという層を設けることがポイントになっています。 LSUDsとは Large Set of Unknown Developers 大多数向けの未知の外部開発者に向けたAPI（自分でコントロールできない人たち） 誰にでも合うフリーサイズの服にちなんで one-size-fits-allAPI とも言う SSKDsとは Small Set of Known Developers 利用者が自分が知っている開発者向けのAPI（自分でコントロールできる人たち） LSUDsなAPIに求められるもの 汎用的 様々なユースケースを満たす 簡単、わかりやすい 機能の単位が小さい リソース指向 RESTful SSKDsなAPIに求められるもの クライアント（デバイス）に寄った実装 クライアントごとに最適化されたAPI 画面を作るためのおまとめAPI
1. The document discusses RESTfulAPIs andgRPC, comparing their characteristics and use cases. 2. RESTfulAPIs typically use HTTP and JSON to access resources via URLs whilegRPC uses protocol buffers and HTTP/2 for efficient streaming and RPC. 3.gRPC is better suited for microservices and mobile apps due toits ability to handle streaming and performance, while REST is more widely used due to i
今日では HTTP(s) でAPI が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々のAPI の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTPAPI にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTPAPIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
Pagination is atechnique forbreaking large record sets into smaller portions called pages. As a developer, you should be familiar with implementing pagination, but implementing pagination for real time data can become tricky even for experienced developers. In this tutorial, we aregoing to discuss the practical use cases and solutions for real time data pagination and cursor based pagination. K
最近のウェブ開発では各機能ごとをAPIでつなぎ込む時代になっています。 そのため、各チームが開発をしていく上で、 他のチームにAPIの仕様を伝える方法をきちんとまとめておく必要が出てきています。 そんな中でAPIドキュメントにどのような役割が求められていて どのような選択肢があるか、一旦自分の把握している知識をまとめています。 (ここで書いているAPIは、httpでアクセスしたら、JSON形式でレスポンスを返すウェブサービスのAPIを指しています)APIドキュメントを用意する上で、すぐにぶつかる壁APIドキュメントを用意する場合に、何も考えずにExcelやwikiにまとめると、早い段階で メンテナンスのコスト の問題にぶつかります。 『APIドキュメントを書く時間がない』 『本当にドキュメント通りの結果が返ってくるか、試してみないとわからない』 『実際に返ってくるAPIとレスポンスが違
2. ⾃⼰紹介と今回のLTの内容 • スマホゲーム開発でテックリードをやっています。 • クライアントサイド: C#(Unity) • サーバサイド:Scala(Play) • 今年リリースしたゲームのWebAPIサーバの開発でメッセージ フォーマットとしてThriftを導⼊した件について話します。 • RPCフレームワークとしてのThriftの話ではないのでご注意。 4. メッセージフォーマットの選定 • 新規にゲームを開発するにあたって、2014年の終わり頃にメッセー ジフォーマット(シリアライザ)の選定を⾏いました。 •APIレスポンスやマスターデータなどで利⽤ • JSONのつらみ • 前タイトルまではJSONを利⽤ • パフォーマンスが出ない、メモリ消費が⼤きい (巨⼤なJSONを返すとゲームが⼀瞬⽌まってしまうことも) • ⻑期運⽤しているとレスポンスのフィールドが何を意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
