今回はバックエンドAPIでページネーションをどうやるかについての話なので、よくある無限スクロールUIのようなフロントエンド側の実装に関する話はしない。あくまでもAPI、もっと言えばRESTfulなAPIのリクエスト・レスポンスにおけるページネーションの話。 本気で深く考えるというよりざっくり検討したときの話です。 はじめに REST APIを実装するにあたってリスト系のAPIを提供する場合に必須といっても過言ではないのがページネーション。大量のリソースをレスポンスする場合にそれらを一気に返してしまうことは応答速度、転送量、クライアントサイドでの扱いづらさなどなどに繋がるので必須と言える。 最近、新たなAPIを開発するにあたってページネーションをする必要があったこともあり、今回はこのページネーションをどうやって提供するか整理して改めて検討してみた。 前提 TypeScript Nest.js
※この投稿は米国時間 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 をその基盤
Graphiti makes RESTful Resources a first-class concept. This enables reading and writing a graph of data in a single request, a schema with backwards-compatible guarantee, end-to-end integration test patterns, seamless microservices and much more. If you just want to get a 5-minute feel for Graphiti code and all the functionality that comes out-of-the box, head to the Quickstart. If you want a bir
I've not blogged in quite a while here -- lots of reasons, none of them sufficient. So, today, i break the drought with a simple rant. Enjoy -- mca It is really encouraging to see so many examples of companies and even industries spending valuable resources (time, money, people) on efforts to define, implement, and advocate for "open" APIs. in the last few years i've seen a steady rise in the numb
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
概念としてとしてのRESTは、 Roy Fielding が博士論文「 Architectural Styles and the Design of Network-based Software Architectures 」で導入したものです。その16年後、アーキテクチャとしてのRESTは、APIを設計・構築するための最も広く受け入れられた方法となっています。RESTについては私たちはみんな聞いたことがありますし、自分たちが実際にRESTfulなAPIを構築しているとほぼ皆が思っています。しかし、それは本当でしょうか？ 「RESTとは何か？」ということを自分たちにもう一度思い出させたうえで、さらにRESTを補う別の方法、「HATEOAS」と呼ばれるものの話に続けていきましょう。 RESTとは何か？をもう一度 私はこれを説明するための良い方法について考えていたのですが、Ryan Tomak
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTf
How and why should you use JSON API in your Rails API? … and check why 5600+ Rails engineers read also this That’s it. Because it is the RC version it is unfortunately not supporting the whole JSON API spec (for example it’s hard to embed links inside relationships), but the codebase is still growing. Configuration With 0.10.x versions of Active Model Serializers uses the idea of adapters to suppo
About the content This content has been published here with the express permission of the author. Current methods of API versioning don’t actually solve the problem of breaking changes — they just delay them. Kyle Fuller presents the REST architecture as a means of allowing changes in API & API clients to develop independently. While dispelling common misconceptions about REST, he’ll demonstrate h
RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに 10年以上前、XMLの登場に続いてXMLベースのAPIを記述する標準フォーマット「WSDL」が提唱されました。 WSDLにはAPIの仕様がマシンリーダブルな形で記述されており、APIを呼び出すためのプロトコルやデータフォーマットをあらかじめ知ることができます。WSDLを利用することで、APIをコールするためのコードを自動生成することが可能でした。 しかしXMLベースのAPIは期待されたほど普及せず、現在ではよりシンプルなRESTful APIが事実上の標準となっています。 そしてRESTful APIのためのWSDLとも言うべき、RESTful APIのインターフェイスを記述するための標準フォーマットを推進する団体「Open AP
samuelrodgers752 | Flickr - Photo Sharing! RoarはRepresenterを使ってRESTなAPIをパース、レンダーすることができるgemです。 つまり、Roarを使うことで、RailsでJSONを返すAPIサーバーを作成したり、逆に、APIサーバーにアクセスするAPIクライアントをRubyで作れます。 下記に記載しましたが、有名なgemに比べて、メリットとしては、Rubyでサーバーとクライアントを作る場合、同じような箇所を幾分か共有できる点です。 デメリットとしては、個人的にパースやレンダー時にエラーが発生してもデバッグしづらく対処しづらいことです。 サーバー側でAPIを作る場合、「Ruby Toolbox - API Builders」によると、jbuilderやGrape、Rablなどが人気のようです。 APIにアクセスするクライアントを作
API言語は揺籃期にある。その開発者たちは先駆者であり，それぞれの仕事に最適な技術を選択している。今年初めにInfoQは，API仕様の選択肢に関してHacker Newsで交わされた，活発な議論を取材した。 コミュニティでの議論から分かるのは，ただひとつの標準というものは存在しない，ということだ。API開発者たちはAPI BlueprntやRAML，Swaggerなどを積極的に利用すると同時に，コミュニティとして協力して，将来使用される標準の定義に取り組んでいるのが現状だ。 InfoQは先日，ApiaryのCEOであり，API Blueprintプロジェクトの創始者でもあるJakub Nesetril氏と話す機会に恵まれた。 InfoQ: API Blueprintの目的と，開発のきっかけについて教えて頂けますか？ Jakub Nestril: API Blueprintは RAMLより早
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
