移転しました http://please-sleep.cou929.nu/20130121.html
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
JSON Schema で Web API のスキマを埋めよう
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
バッチリクエスト - グラフAPI - ドキュメンテーション - Meta for Developers
複数のFacebookグラフAPI呼び出しを含む、単一のHTTPリクエストを送信します。独立した操作は並列で処理され、依存関係を持つ操作は順番に処理されます。すべての操作が完了すると、集約された応答が返され、HTTP接続が閉じられます。 応答の順序は、リクエスト内の操作の順序に対応します。それに応じて応答を処理し、成功した操作と、その後の操作で再試行する必要があるものを判別する必要があります。 制限 バッチに含めるリクエストは、1つのバッチにつき50個に制限されています。API呼び出し制限とリソース制限を計算するため、バッチ内の各呼び出しは個別にカウントされます。たとえば、1つのバッチに10個のAPI呼び出しが含まれる場合、呼び出しは10回としてカウントされます。また、バッチ内の個々の呼び出しは、CPUリソース制限でも同様にカウントされます。詳しくは、「レート制限ガイド」をご覧ください。
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
10 Best Practices for Better RESTful API | Thinking Mobile
Do not use verbs: /getAllCars /createNewCar /deleteAllRedCars 2. GET method and query parameters should not alter the state Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET for state changes: GET /users/711?activate or GET /users/711/activate 3. Use plural nouns Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all r
Flask-RESTful — Flask-RESTful 0.3.10 documentation
Flask-RESTful¶ Flask-RESTful is an extension for Flask that adds support for quickly building REST APIs. It is a lightweight abstraction that works with your existing ORM/libraries. Flask-RESTful encourages best practices with minimal setup. If you are familiar with Flask, Flask-RESTful should be easy to pick up. User’s Guide¶ This part of the documentation will show you how to get started in usin
RESTful Authentication
How to handle authentication in a RESTful Client-Server architecture is a matter of debate. Commonly, it can be achieved, in the SOA over HTTP world via: HTTP basic auth over HTTPS; Cookies and session management; Token in HTTP headers (e.g. OAuth 2.0 + JWT); Query Authentication with additional signature parameters. You'll have to adapt, or even better mix those techniques, to match your software
node.jsでREST APIを作るのに最適なexpress-resource | Inhale n' Exhale
「node.jsを使って簡単にWebアプリが作れる！」みたいな記事で紹介されているサンプルコードは、だいたいそのまま使いものにならないことが多い。実際のアプリ開発では、いろいろなモジュールをNPMでインストールして、ソースコードツリーの階層なんかにも気を配ったりするものだ。DBへのアクセスも一元化して、O/Rマッパーも使えるようにしたい。国際化対応も考えなければならない。デバッガも必要だ。アプリを作りながら後付していくのもいいが、最初の段階である程度は固めておきたいと思う人も多いだろう。 すべてを一気に紹介すると相当長くなりそうなので、今回はREST APIを作る上で欠かせないexpressとexpress-resourceに焦点を当てる。node.jsとNPMをまだインストールしていなかったらnvmでインストールしておこう。 node.jsでMVCアーキテクチャのアプリを作ろうと思ったら
Creating a RESTful Python API with Bottle || Fritz Stelluto
I used Bottle, a Python framework, to create a quick and dirty RESTful service to allow simple CRUD operations on a bunch of XML files. About the task This is part of an larger, abondoned project, a simple recipe manager. Previous steps had left me with a set of XML files I can visualize in a browser by applying XSLT to them. I now need a quick and dirty way to manage those files directly from the
REST における PUT メソッドと POST メソッドの違い - 星一の日記
最近 REST に関する本を読んでいます。統一された少ないルールで、さまざまな Web アプリケーションを表現できるというのは、妄想が膨らんでワクワクしますね。学んだことをメモがてらに書きます。 RESTful Webサービス 作者: Leonard Richardson,Sam Ruby,山本陽平,株式会社クイープ出版社/メーカー: オライリー・ジャパン発売日: 2007/12/21メディア: 単行本購入: 25人 クリック: 842回この商品を含むブログ (168件) を見る PUT も POST も似た役割をもつメソッドです。両方ともリソースの新規作成または更新を行います。この二つのメソッドは何が異なり、どのように使い分けるべきなのでしょうか。 リソースの新規作成 まずリソースの新規作成について。 PUT は URI が指し示すリソースを直接作成することを、サーバーに要求します。たと
Social Website Tutorial (v0.9) - OpenSocial
OpenSocial Foundation Moves Standards Work to W3C Social Web Activity W3C and the OpenSocial Foundation announced today that as of 1 January 2015, OpenSocial standards work and specifications beyond OpenSocial 2.5.1 will take place in the W3C Social Web Working Group, of which the OpenSocial Foundation is a founding member. The W3C Social Web Working Group extends the reach of OpenSocial into the
yohei-y:weblog: HTTP ステータスコードを正しく使おう
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - subosito/iglo: API blueprint's formatter
RESTful Web アプリの設計レビューの話
koshigoewiki:rest:第８回xml開発者の日 [KoshigoeWiki]