『RESTful Web Services Cookbook』Chapter10 条件付きリクエスト - winplusの日記
『RESTful Web Services Cookbook』から。 Chapter10 条件付きリクエスト ふたつの課題を解決するために、条件付きリクエストが役に立ちます。GETリクエストにたいしては、条件付きリクエストはクライアントとキャッシュがキャッシュされた表現が最新かどうかを判断するのに役立ちます。PUT、POST、DELETEのような安全でないリクエストにたいしては、条件付きリクエストは同時並行処理の制御を提供します。 条件付きGETをサポートすれば、性能が改善されます。同時並行処理の面からいえば、PUT、POST、DELETEのような安全でないリクエストを条件付きで行わないと、アプリケーションの整合性に影響を与えてしまうかもしれません。適切な同時並行処理のチェックがない場合、サーバーは「更新の喪失」や「遅延した削除」を受け入れてしまいます。クライアントが変更あるいは削除のリク
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
複数のリソースに一度にアクセスしたいときのURL設計 - ぶろぐ。@はてな
「RESTとRailsスタイル]」のときに、@shu_0115さんから「複数同時に書き込みたいときはどうするか」という質問がありました。これは実用上はなかなか重要な点だと思うので、少しまとめます。 親子関係のリソースを更新 例えば /users/123 と /users/123/profile を両方変更したいなど。 この場合は、親に対するリクエスト PUT /users/123だけですませるのが一般的です。POSTでユーザを新規作成するときも、自動的に子のリソースが作られたとみなしますよね。 複数のMemberリソースを更新 例えば /posts/1 /posts/2 /posts/3 の3つの投稿に同時に「rest」タグをつける、というUIがあるかもしれません。 この場合、とくにアトミックな必要はないので、Ajaxでリクエストを3回送ってもかまわないのですが、3個ならまだしも10個など
InfoQ: 実践RESTful HTTP
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
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
yohei-y:weblog: REST 入門(その8) REST でないもの
» REST 入門 目次 WWW は REST アーキテクチャスタイルのアーキテクチャを採用した実装のひとつですが、 REST アーキテクチャスタイルでないアーキテクチャの WWW アプリケーションもかなり存在します。 REST でないものを一言で言ってしまうと、 URI と HTTP を正しく使っていないもの、ということになります。 以下では URI と HTTP の誤った使い方について説明します。 URI をクライアントで組み立てる URI をクライアント側でごちょごちょ組み立てなければならないのなら、それは REST ではありません。 たとえば、はてなブックマーク AtomAPI が、こんなインターフェースだったらどうでしょう? ブックマークをキーワードで検索する。 POST /uso/bookmarkSearchService HTTP/1.1 Host: b.hatena.ne.
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tender Surrender » Runtime error