RESTとは

RESTはWebのアーキテクチャスタイル。実際のアーキテクチャを設計するときの指針だったり、作法だったりするもの。
RESTは複数のアーキテクチャスタイルを組み合わせて構築した複合アーキテクチャスタイル。
基本はクライアント/サーバーで、そこに制約を課していくことでRESTを構成していく。

クライアント/サーバー

そもそもWebはクライアント/サーバーのアーキテクチャスタイルを採用しているので、クライアント/サーバーが基本になる。
クライアントとサーバーに分離することでマルチプラットフォームにすることができる。
これをもとに以下の制約を課していく。

クライアントの状態をサーバーで保持しない。
クライアントの状態を保持しないことで実装を簡単にすることができる。

一度取得したリソースをクライアント側で保存し使いまわす。
クライアント/サーバー間での通信を減らすことができる。

URIで指し示したリソースに対する操作を統一した限定的なインターフェースで行う。

ここがちょっと分かりにくいですね。

まず統一の部分ですが、GETといえばリソースの取得で、POSTといえばリソースの更新ですよね？
このように操作を統一することで、リソースの提供者はRESTに従えば正しくリソースを提供でき、クライアントもRESTに従って要求すれば正しくリソースが取得できるわけです。

つぎに限定的な部分ですが、HTTP1.1ではGETやPOSTなど8個のメソッドが定義されています。
このようにメソッドを限定することでアーキテクチャをシンプルに保ちます。

全てのサーバーが同じインターフェースを採用することで(RESTに則ることで)、正しくリソースのやりとりができるね！ってかんじです。

階層化システムは統一インターフェースの利点でもあります。
クライアント側からしてみれば、直接通信するところのインターフェースが統一されていれば通信できるわけです。
それより先のことは特に気にする必要はないので、プロキシやロードバランサを挟んだりして階層化することができます。

プログラムをクライアント側で実行すること。JavaScriptとか。
(RESTの提唱者であるFieldingの博士論文ではオプション扱いだった。)

上記すべてのアーキテクチャスタイルを追加したものがULCODC$SS(Uniform Layered Code on Demand Client Cache Stateless Server)です。

これだけみるとRESTAPIってハードル高いなあと思います。
ただRESTはあくまでアーキテクチャスタイルなので、実際にシステムを設計するときにはいくつか除外してもOKなのです。ほとんどを除外してしまう場合はRESTではないアーキテクチャスタイルを採用するべきでしょう。