[18] REST は、 Web のプロトコルや API の設計に大きな影響を与えた体系様式です。
[19] 現在ではバズワードとなった「REST」の意味は発散しており、 「Web を使った何か」程度の言葉と理解するべきかもしれません。
[30] REST に沿っていることを RESTful といいます。
[31] REST に従っていると設計者または利用者等が特に主張しているプロトコルには、 次のものがあります。
[32] その他いろいろな Web API が RESTful であるなどと主張しています。
[61] 沢山あってきりがないですが、中でも特に REST であることを強く主張しているもの:
[41] REST にしようという話をよく聞いてみると、 HTTP を正しく使おうというだけの話だった、ということもあります。
[14] 近年の「REST」API の類は従来 URL に含めていたデータを HTTP の機能で表すのが cool だと思っているようです。 そのような例は:
[20] こういうのって「なんでも URI で表せる」という Semantic Web 的世界観とは矛盾する気がしますが、 REST 系の人は気にしないのですかね。
[29] 実際不便だからか何なのか、ヘッダー等による指定だけでなく URL query などの指定もできるようにしている API も少なからずあります。 実装コストや不具合リスクが上がるだけで何も得していない気がしますが・・・。
[25] 関連する JSON Web API の URL を JSON 応答内に含める HAL 的なものを好ましいと思っている人達 (その人達もそのやり方が REST っぽくて cool だと思っていそう...) のやり方とも衝突するような気がしないでもない。。。
[43] URL 相当のものを URL 以外で表す他にも、 次のようなものが REST 的であると評されたり、 REST の条件であると主張されたり、 REST を名乗る API が使っていたりします。 (色々な派閥があるようで、 相互に矛盾したものもありますが...)
[66] URL に「/api/」のような文字列を含めることも、
REST 信奉者的には余り問題が無いみたいです (もしかすると派閥もあるのかもしれませんが)。
Cool URI 教では好かれない設計のような気がします。
それとも拡張子ではないから特に問題ない、ということなのでしょうか。
[68] URL に API のバージョンを入れるというのも、 Cool URI とは正反対の考え方ですよね。。。
[72] 具体例は悪いWeb API設計も参照。
[38] 次のものは REST と対立する技術だったり、 REST でないと言われたりする要素です。
[35] RPC は REST でないというのが一般的な見解のようですが、 RPC を REST で作ったなどと主張するものもあったりするようです。
[36] REST-RPC が REST なのか RPC なのか両方なのかどちらでもないのかよくわかりません。 REST-RPC が REST であったり REST でなかったりすることもあるようです。
[37] SOAP は元々 REST とは対立するものだったのが、 W3C で SOAP 1.2 を開発した結果 REST になった、とされています。
[1] 傭兵日記: REST の日本語リソース http://yohei-y.blogspot.com/2004/12/rest.html (名無しさん)
妙に理解力のある奥さんだw (名無しさん)
[3] 傭兵日記: REST 入門 http://yohei-y.blogspot.com/2005/04/rest_23.html (名無しさん)
[4] REST - 羊堂本舗 ちょき http://sheepman.parfait.ne.jp/wiki/REST (名無しさん)
[5] Architectural Styles and the Design of Network-based Software Architectures http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (名無しさん)
[6] 川o・-・)<2nd life - RESTWiki http://d.hatena.ne.jp/secondlife/20050914/1126631161 (名無しさん)
[7] はてなブックマーク - 第八回XML開発者の日 http://b.hatena.ne.jp/entry/http://www.asahi-net.or.jp/~eb2m-mrt/kaihatsu8.html (名無しさん 2005-11-26 01:55:52 +00:00)
[8] REST でよくある間違い http://www.geocities.jp/yamamotoyohei/rest/mistakes.html (名無しさん 2005-11-27 02:02:40 +00:00)
[9] rest - Microformats http://microformats.org/wiki/rest/
(名無しさん 2005-11-29 10:24:42 +00:00)
[10] RestWiki: Front Page http://rest.blueoxen.net/cgi-bin/wiki.pl?FrontPage (名無しさん 2006-07-16 08:42:33 +00:00)
[26] 最初は XML-RPC や SOAP のようなものに対する REST という対立構造だった気がしますが、いつの間にか SOAP 1.2 は「REST に基づいている」 みたいなことになっていた。。。
[11] スラッシュドット ジャパン | ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解 http://slashdot.jp/security/article.pl?sid=06/10/17/1958219&from=rss (名無しさん 2006-10-20 00:35:24 +00:00)
[27] その後 SOAP などが話題にもならなくなって、 REST という言葉も忘れ去られていくのかと思っていたら、 10年代になってまた (10年ぶりくらいに) 流行りだした...
[13] 最近は REST の意味もよくわからなくなってきましたね。みんな自分の好きなスタイルのことを REST と呼んで自己正当化してるだけのような・・・。
[12] RESTful API Design, Second Edition ( ( 版)) http://www.slideshare.net/apigee/restful-api-design-second-edition
[21] 続・コマンド的な処理をどうやってRESTfulに実装するか - 岩本隆史の日記帳 ( ( 版)) http://d.hatena.ne.jp/IwamotoTakashi/20090326/p1
[22] 技術/HTTP/REST設計思想の "Stateless" との付き合い方 - Glamenv-Septzen.net ( 版) http://www.glamenv-septzen.net/view/1350
[34] REST APIs must be hypertext-driven » Untangled ( 版) http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
[39] REST API は URL が割り当てられた各オブジェクトを個別に取得したいときは単純で良いのですが、 複数まとめて取得したいとき、標準的な方法が用意されていないのが困りものです。 実装依存の方法で、複数のオブジェクトを query で指定したり、 複数のHTTP要求をひとまとめにしたりすることができる場合もあれば、 そのような方法が何も用意されていない場合もあります。
[40] 持続的接続や HTTP/2 を使えばいいと考える人もいるのでしょうが、 サーバー側もたぶん複数回のデータベースアクセスが発生するよりまとめて一度に取得できる方が負荷その他の点から嬉しいはずです。
One of the key constrains on REST is that a RESTful API must use hypermedia formats (the HATEOAS constraint).
RESTの使用例の一つに「RSS配信」がある。RSS配信では、特定のURLにアクセスすると、XMLのRSSフォーマットで記述されたデータが配信される。
明確な仕様がないために「どこまでをRESTと呼ぶか」については様々な主張があるが、ここでは『HTTPのGETメソッドを使ってあるURLにアクセスすると、XMLが返ってくる』ものをRESTと呼ぶ。セッションやPOSTを使えば複雑な事も実現可能だが、今回はGETを使ったシンプルなRESTを想定している。
一般によく使われる狭義のRESTは、パラメータを指定して特定のURLにHTTPでアクセスすると、XMLで記述されたメッセージが送られてくるようなシステムおよび呼び出しインターフェース(「RESTful API」と呼ばれる)のことを指す。システムの状態やセッションに依存せず、同じURLやパラメータの組み合わせからは常に同じ結果が返されることが期待される。ただし、厳密な技術的定義が共有されているわけではなく、「SOAPやRPCなどを必要としない、XMLベースの単純なWebインターフェース」くらいの意味で用いられる場合が多い。
PUT/DELETEをしたいときは、httpのメソッド的にはPOSTを使いながらも、
これはPUTです、これはDELETEです、というフラグを合わせることで、
RESTfulっぽいインターフェースを実現しています。
これが擬似REST方式です。
[57] 調査:著名サイトのパスワードリセット用 URL - Qiita ( ()) http://qiita.com/t-suwa/items/f3969be0fdf21112e8fe
The Apple News API has typical RESTful characteristics:
Has a set of resources; for example, channels and articles
Provides stateless create, read, update, delete (CRUD) operations on resources
Uses JSON (application/json) for input and output
Microsoftが「RESTful」なAPIを作成するためのガイダンスを公開した。Roy Fielding氏は、そのAPIを (RESTとほとんど関係ない) HTTP APIと見なしている。
Representational State Transfer(REST)は、SOAPなどの追加メッセージング・レイヤなしで、標準化されたインタフェース(HTTPなど)を介してデータを送信する単純なインタフェースを記述するものです。RESTには、ステートレス・サービスを作成するための一連の設計ルールが用意されており、これらはリソース(特定の情報のソース)として表示されます。それぞれのリソースは固有のURIで識別できます。クライアントがURIを使用してリソースにアクセスすると、標準化された固定のメソッド・セットと、リソースの表示が返されます。クライアントは、新しい各リソース表示を使用してステートを転送します。
Rather than construct several REST requests to fetch data that you're interested in, you can often make a single call to fetch the information you need.
The API is RESTish. The goal is not to follow REST's practices closely, but rather to make an easy API to get up to speed with using a dynamic language or curl.