Representational State Transfer

Representational State Transfer (REST、レスト) は、（ウェブアプリケーションプログラミングインタフェース）の定義に使用されるアーキテクチャスタイル（共通仕様）であり、同時にウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつでもある。この語はHTTPプロトコル規格の主要著者の一人であるがウェブについて書いた2000年の博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。
RESTは、初めはアーキテクチャの原則と制約の集まり（後述）を指していたが、次第に、XMLやHTTPを使った簡易なウェブベースのインタフェースのうち、WebサービスのSOAPプロトコルのようなMEP（"Message Exchange Pattern"; SOAPノード相互のメッセージ交換のパターンを確立するための雛型）ベースの特別な抽象化をしないもののことを、大まかに意味する用語として使われるようになった。RESTは次に述べるように2つのやや異なる意味で使われている。
RESTはこのように2つのやや異なる意味で使われているため、技術的な議論の中で混乱を引き起こすことがある。
ただし、RPCはRESTの実例とはいえない。
フィールディングのREST原則に従うシステムは、しばしば"RESTful"といわれる。RESTをとても熱心に支持する人々は自らのことを"RESTafarians"と呼ぶ。ちなみに、この呼称は「ラスタファリアン」（）のもじりである。
人工知能が流行している今、IBMはAIやデータサイエンスを研究するための基本ツールとしてRESTを掲げている。
原則.
RESTを支持する人々は、ウェブのスケーラビリティと成長は、次に述べるような、いくつかのキーとなる設計原則の結果であると論じる。
リソース.
REST において重要な概念は、「リソース」(情報の断片) である。個々のリソースは、グローバルな識別子 (URI) により参照することができる。リソースに対する操作は次のようにして行われる。
しかし実際のところこうしたリソース操作は議論の対象となっている。一部の人々には「リソース」と「表現」とを区別することは観念的すぎるとの意見がある。ただし RDFコミュニティでは、リソースと表現の区別は、一般的に行われている。
さまざまな「コネクタ」（クライアント、サーバ、キャッシュ、トンネル など）がリクエストを仲介することができる。ただしコネクタは過去のリクエストを参照せずに仲介することができなければならない。
こうすることで、RESTアプリケーションは、次の2つの情報を認識することで、リソースを扱うことが可能である。
アプリケーションと実際の情報を持つサーバとの間にある他のものについて意識する必要はない。つまりアプリケーションは、キャッシュやプロキシ、ゲートウェイ、ファイアウォール、トンネルなどの有無を意識する必要は無い。
ただしアプリケーションは、返された情報（表現）のフォーマットを理解できる必要がある。そのフォーマットは、多くの場合は何らかのHTMLかXMLの文書であるが、場合によっては画像やその他のコンテンツであることもある。
REST対RPC.
RESTなウェブアプリケーションは、遠隔手続き呼出し (RPC) アプリケーションとは異なる設計面のアプローチを必要とする。RPCでは、プロトコル操作（動詞）の多様性を重視する。RPCアプリケーションが定義する操作の例を次に示す。
 getUser()
 addUser()
 removeUser()
 updateUser()
 getLocation()
 addLocation()
 removeLocation()
 updateLocation()
 listUsers()
 listLocations()
 findLocation()
 findUser()
一方RESTでは、リソース（名詞）の多様性を重視する。RESTアプリケーションが定義するリソースの型の例を次に示す。
それぞれのリソースは、http://www.example.org/locations/us/ny/new_york_city のような固有のURIを持つ。このリソースを扱うクライアントは標準のHTTPメソッドを使う。例えば、
なお、それぞれのリソースが固有のURIを持っているので、キャッシュ、コピー、ブックマークすることが簡単にできることに注意してほしい。HTTP POSTは一般に副作用のあるアクションに対して使われる。たとえば購入の注文を行ったり、コレクションに情報を追加したりするために使われる。 
一例として、次のようなXML形式のユーザーのデータを扱うことを考える。
<user>
 <name>Jane User</name>
 <gender>female</gender>
 <location href="http://www.example.org/locations/us/ny/new_york_city">
 New York City, NY, US
 </location>
</user>
ユーザーのlocation（住所）を更新するためには、RESTクライアントはまず上記のXMLデータをHTTP GETによりダウンロードする。それからXMLデータのlocationを変更して、HTTP PUTによりアップロードする。
HTTPのメソッドが、リソースを発見するための標準的なメソッドをすべて提供してはいないことに注意してほしい。
RESTは、その代わりに、扱う対象とするコレクションや検索結果の集合を、別の型の「リソース」として扱うことで問題に対処する。アプリケーション設計者は、リソースの検索や一覧取得のために状況に応じてそのURIやURIパターンを知っておく必要がある。
いくつかの例を示す。
RESTは、このようなアクションをどのように行うかについてのいくつかの手がかりを提供する。この手がかりは、RESTの原則を構成する制約の一つ「アプリケーション状態のエンジンとしてのハイパーメディア」から得られる。この制約から導かれる実現手段の一つは、パラメタつきのリクエストに対しては、フォーム言語（HTMLフォームなど）を使うことである。
A9.comのOpenSearchイニシアチブは、RESTを使った検索の標準化作業を行っている。具体的には、RDF、XTM、Atom、RSS（方言を含む）、リンクを扱うためのXLinkと組み合わせた簡単な構造のXML (Plain Old XML; POX) を含む一般的なフォーマットをRESTシステムで使うことにより、情報を発見するための規格の策定である。
公開されている実装.
RESTはかなり広い意味で定義されているので、広義に捉えると非常に多くの数のRESTfulアプリケーション（HTTP GETリクエストによりアクセス可能なすべてのもの）がウェブ上に存在すると考えることができる。RESTを、一般的なWebサービスやRPCスタイルとは異なるものとして狭義に捉えても、RESTは公開されたウェブ上の随所に見つけることができる。
同様のものが他にも多く提供されているとみられる。
なお、上記の多くのものは完全にRESTfulというわけではない。つまり、それらは REST の全てのアーキテクチャの制約に従っているわけではない。とはいえ、どれもRESTから刺激を受けたものであり、RESTのほとんどのアーキテクチャの制約の重要性を認識している。特に統一的なインタフェースの制約についてはそうである。これらのサービスは「偶然によるRESTful」と呼ばれることがある。