この記事には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2023年11月）
.mw-parser-output .hatnote{margin:0.5em 0;padding:3px 2em;background-color:transparent;border-bottom:1px solid #a2a9b1;font-size:90%}

「REST」はこの項目へ転送されています。reSTと表記される 軽量マークアップ言語については「reStructuredText」をご覧ください。

Representational State Transfer (REST、レスト[1][2][3][4]) は、ウェブAPI（ウェブアプリケーションプログラミングインタフェース）の定義に使用されるアーキテクチャスタイル（共通仕様）[5]であり、同時にウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつでもある。この語はHTTPプロトコル規格の主要著者の一人であるロイ・フィールディング（英語版）がウェブについて書いた2000年の博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。

RESTは、初めはアーキテクチャの原則と制約の集まり（後述）を指していたが、次第に、XMLやHTTPを使った簡易なウェブベースのインタフェースのうち、WebサービスのSOAPプロトコルのようなMEP（Message Exchange Pattern; SOAPノード相互のメッセージ交換のパターンを確立するための雛型）ベースの特別な抽象化をしないもののことを、大まかに意味する用語として使われるようになった。RESTは次に述べるように2つのやや異なる意味で使われている。

フィールディングのRESTアーキテクチャスタイルの原則に合わせたWebサービスシステム。

遠隔手続き呼出し (RPC) スタイルに合わせた簡易なXML + HTTPインタフェースを採用したシステム（SOAPは使わない） 。

RESTはこのように2つのやや異なる意味で使われているため、技術的な議論の中で混乱を引き起こすことがある。ただし、RPCはRESTの実例とはいえない。

フィールディングのREST原則に従うシステムは、しばしばRESTfulといわれる。RESTをとても熱心に支持する人々は自らのことをRESTafariansと呼ぶ。ちなみに、この呼称は「ラスタファリアン」（英: Rastafarians）のもじりである。

人工知能が流行している今、IBMはAIやデータサイエンスを研究するための基本ツールとしてRESTを掲げている[6]。
原則

RESTを支持する人々は、ウェブのスケーラビリティと成長は、次に述べるような、いくつかのキーとなる設計原則の結果であると論じる。
ステートレスなクライアント/サーバプロトコル
HTTPメッセージの一つ一つが、そのリクエスト（メッセージ）を理解するために必要な全ての情報を含む。そのため、クライアントもサーバも、メッセージ間におけるセッションの状態を記憶しておく必要がない。ただし実際には、多くのHTTPベースのアプリケーションはクッキーやその他の仕掛けを使ってセッションの状態を管理している（URLリライティングのような一部のセッション管理手法を使うシステムは、RESTfulではない）。
すべての情報（リソース）に適用できる「よく定義された操作」のセット
HTTP では操作（メソッド）の小さなセットが定義されている。最も重要なのは "GET"、"POST"、"PUT"、"DELETE" である。これらはデータ永続化に要求されるCRUDと比較されることがある。もっとも "POST" に関してはCRUDにはぴったり対応していない。
リソースを一意に識別する「汎用的な構文」
RESTfulなシステムでは、すべてのリソースはUniform Resource Identifier (URI) で表される一意的な（ユニークな）アドレスを持つ。
アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
RESTシステムでは、多くの場合、HTML文書またはXML文書を使う。こうした文書に情報およびその他のリソースへのリンクを含める。こうすることにより、あるRESTリソースから他のRESTリソースを参照したい場合は単にリンクを辿るだけでよい。レジストリなどの他の基盤的な機能を使う必要はない。
リソース

REST において重要な概念は、「リソース」(情報の断片) である。個々のリソースは、グローバルな識別子 (URI) により参照することができる。リソースに対する操作は次のようにして行われる。

ネットワークの「コンポーネント」(クライアントやサーバ) が、標準化されたインタフェース (HTTP) により通信する。

ネットワークを介してリソースの「表現」（英: representation）を交換する（実際にはファイルがアップロード・ダウンロードされる）。

しかし実際のところこうしたリソース操作は議論の対象となっている。一部の人々には「リソース」と「表現」とを区別することは観念的すぎるとの意見がある。ただし RDFコミュニティでは、リソースと表現の区別は、一般的に行われている。

さまざまな「コネクタ」（クライアント、サーバ、キャッシュ、トンネル など）がリクエストを仲介することができる。ただしコネクタは過去のリクエストを参照せずに仲介することができなければならない。これは REST の原則を構成する「レイヤリング」と呼ばれる制約である。レイヤリングは、情報アーキテクチャやネットワークアーキテクチャの他の多くの部分にも見られる一般的な設計原則でもある。

こうすることで、RESTアプリケーションは、次の2つの情報を認識することで、リソースを扱うことが可能である。

リソース識別子

要求されたリクエスト

アプリケーションと実際の情報を持つサーバとの間にある他のものについて意識する必要はない。つまりアプリケーションは、キャッシュやプロキシ、ゲートウェイ、ファイアウォール、トンネルなどの有無を意識する必要は無い。

ただしアプリケーションは、返された情報（表現）のフォーマットを理解できる必要がある。そのフォーマットは、多くの場合は何らかのHTMLかXMLの文書であるが、場合によっては画像やその他のコンテンツであることもある。
REST対RPC

RESTなウェブアプリケーションは、遠隔手続き呼出し (RPC) アプリケーションとは異なる設計面のアプローチを必要とする。RPCでは、プロトコル操作（動詞）の多様性を重視する。RPCアプリケーションが定義する操作の例を次に示す。getUser()addUser()removeUser()updateUser()getLocation()addLocation()removeLocation()updateLocation()listUsers()listLocations()findLocation()findUser()

一方RESTでは、リソース（名詞）の多様性を重視する。RESTアプリケーションが定義するリソースの型の例を次に示す。 User {} Location {}

それぞれのリソースは、http://www.example.org/locations/us/ny/new_york_city のような固有のURIを持つ。このリソースを扱うクライアントは標準のHTTPメソッドを使う。例えば、

HTTP GETを使ってリソースのコピーをダウンロードする。

更新したコピーをHTTP PUTによりアップロードする。

HTTP DELETEによりそのリソースの全ての表現を削除する。

なお、それぞれのリソースが固有の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のメソッドが、リソースを発見するための標準的なメソッドをすべて提供してはいないことに注意してほしい。RPCの上記の例における list*() や find*() に相当する、HTTP LISTやFINDのようなメソッドはHTTPでは規定していない。

RESTは、その代わりに、扱う対象とするコレクションや検索結果の集合を、別の型の「リソース」として扱うことで問題に対処する。アプリケーション設計者は、リソースの検索や一覧取得のために状況に応じてそのURIやURIパターンを知っておく必要がある。