バッチリクエスト - グラフAPI - ドキュメンテーション - Meta for Developers
複数のFacebookグラフAPI呼び出しを含む、単一のHTTPリクエストを送信します。独立した操作は並列で処理され、依存関係を持つ操作は順番に処理されます。すべての操作が完了すると、集約された応答が返され、HTTP接続が閉じられます。 応答の順序は、リクエスト内の操作の順序に対応します。それに応じて応答を処理し、成功した操作と、その後の操作で再試行する必要があるものを判別する必要があります。 制限 バッチに含めるリクエストは、1つのバッチにつき50個に制限されています。API呼び出し制限とリソース制限を計算するため、バッチ内の各呼び出しは個別にカウントされます。たとえば、1つのバッチに10個のAPI呼び出しが含まれる場合、呼び出しは10回としてカウントされます。また、バッチ内の個々の呼び出しは、CPUリソース制限でも同様にカウントされます。詳しくは、「レート制限ガイド」をご覧ください。
Web API Design(その１) - winplusの日記
これApigee | Google Cloud Blogを勝手訳してみる。InfoQの紹介記事Web API Design - 開発者が愛するインターフェイスを作るで十分かも知れませんが、まあ。 導入 これを読んでいるということは、開発者に愛されるようなWeb API をデザインすることを気にかけているのでしょう。そして、実証済のデザインの原則とベストプラクティスとをWeb APIに適用することに関心があるのでしょう。 私たちがデザインを考えるのためのソースのひとつに、RESTがあります。なぜなら、RESTは厳格な標準ではなくアキーテクチュア・スタイルであり、かなりの柔軟さを認めているからです。構造が柔軟かつ自由であるからこそ、デザインのベスト・プラクティスを貪欲に追い求めるのです。 このe-bookはデザインのプラクティスを集めたものです。収録したプラクティスは、私たちがいくつかの世界中
“API design for humans” をざっくり日本語にしてみた « blog.udzura.jp
37signals Signal vs. Noise で投稿されたブログ記事、面白そうなので日本語にしてみた。特に許可をとってたりとかしてないし、そんな厳密に原文をなぞってないですけど、まあ緩く。原文を必ずあわせて読みましょう。 37signals でデータを取り扱う仕事の終着点のひとつとして、たくさんのバラバラの API を取り扱うことがある – 私は少なくともこの数か月間で、10以上のサードーパーティ API を利用し、それと同時に我々の持っているすべてのパブリック API と、さらに多様な内向けインターフェースを取り扱ってきた。いくつもの違った言語で書かれたラッパーを利用し、いくつかは自分自身で書いた。こんな私が API の設計 – デザインとドキュメントに関して、利用者として強い意見を持っていたとしてもおかしくはないだろう。 私の経験上、 API のユーザビリティに真に関係する要素
API design for humans
One of the things about working with data at 37signals is that I end up interacting with a lot of different APIs—I’ve used at least ten third-party APIs in the last few months, as well as all of our public APIs and a variety of internal interfaces. I’ve used wrappers in a couple different languages, and written a few of my own. It’s fair to say I’ve developed some strong opinions about API design
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
