リソースの状態を表す「何か」を転送するということを表した、Webアーキテクチャスタイルです。スタイルのアーキテクチャとして、ROA(リソース指向アーキテクチャ)などがあります。考え方などが解説されています。考えでシステムを設計したことがない人には、新しい発見があり、とてもわくわくして読むことが出来ます。アプリケーションの設計者、アーキテクトの方が読むと良いと思います。考え方を取り入れたい人に本書はお勧めです。オライリーっぽいちょっとお堅い文章ですが、楽しく読めると思います。何か?の概要を抑えてから読むと、理解が早いと思います。アーキテクチャスタイルです。略で「表現可能な状態」を「転送する」という意味を表しています。商品在庫一覧.htmlというファイルがあるとします。これは商品という「リソース」が在庫であるという「状態」を、HTML形式で「表現」していると見なせます。いうアーキテクチャがあるわけではありません。Architecture:リソース指向アーキテクチャ)というものがあります。リソースを主体として考えていくアーキテクチャのことです。おけるリソースとは、参照(認識)するに値する重要性を持つものとして定義されています。「それに対してハイパーテキストリンクを作成する、それに対して意見または反論する、その表現を取得またはキャッシュする、あるいはその他の操作を実行する」ことがある場合は、それをリソースにすべきである。持っていることがあげられます。違いですが、現在では同じ意味で使われているようです。Locator)は、インターネット上の情報資源を指し示すもので、ホスト名、ポート名、フォルダ名、ファイル名などが含まれています。Name)というものが定義されました。Identifier)もインターネット上の情報資源を指し示すもので、包括的な概念として定義されています。構造的でなければならない。それらの構造は予測可能な方法で区別されなければならない。絶対的なルールではない。構造的である、あるいは予測可能である必要はないが、筆者はそうあるべきだと思っている。通じてアクセスすることができます。本に掲載することが出来るのであればそれはアドレス可能であるといえます。(ブラウザのアドレス)から変化せずにアプリケーションの各機能を実行することが出来ます。これらは、アドレス可能ではない例になります。HTTPがアドレス可能ではなかったら、あるいはGoogle検索がアドレス可能なWebアプリケーションではなかったら、そのURIを本に掲載することは出来ない。検索]ボタンをクリックする」と指示しなければならないだろう。リクエストが完全に分離していることです。リクエストに依存せずに実行できるような場合、ステートレス性が保たれているといえます。ステートレス性は、サーバーが取り得る状態もリソースであり、独自のURIが割り当てられるべきであることを意味する。よってサーバの状態が判断できるようにするべきだということです。特定のリクエストを送るために、あらかじめ別のリクエストを送って、サーバ側の状態を変更しておく必要がないような設計でなければならないということになります。ステート(状態)には二種類あり、一つはクライアント側で維持されるアプリケーション状態と呼ばれる状態で、もう一つは、サーバ上で維持されるリソース状態です。アプリケーション状態とは、アプリケーションのユーザが今どのような状況にいるのか(ログインしているのか?検索結果の3ページ目を表示しているのか?)というものを表したものです。リソース状態とは、各ユーザがどのような状況にいても変わらない情報のことで、これらはサーバ側に格納します。サーバは、クライアントからアプリケーション状態を受け取ると、受け取ったリクエスト情報を元にアプリケーションの状態を復帰します。以前のリクエスト状態を覚えておくというようなことはしません。クライアントから受け取ったリクエストだけを信頼すると嘘の情報を渡される可能性があります。そのため、セッションの仕組みを使い、(仕方なく)サーバ側にユーザ情報を保持しておくという実装が現在では行われています。繰り返しますが、アプリケーションに関する状態情報はクライアント側で保持し、サーバにはリソースの情報しか保持しないというのがステートレス性の特徴になります。HTTPセッションの現在の状態はリソース状態としてサーバーに格納されないが、アプリケーション状態としてクライアントによって追跡され、クライアントがWebでたどるパスから作成される。サーバーは、ハイパーメディア(ハイパーテキスト表現内のリンクとフォーム)を提供することにより、クライアントのパスを導く。接続性ステートレス性のところの最後の引用に記述されている、「サーバーは、ハイパーメディア(ハイパーテキスト表現内のリンクとフォーム)を提供することにより、クライアントのパスを導く。」これが、接続性というものです。知っている必要はなく、この接続性(ハイパーリンク)によって、次のリソースや次のサーバ状態に移行できることが重要です。次はこっちの状態かこっちの常態化どちらかがありますよというサーバの提案がアプリケーションを構成しているので、リンクっていうのはすごい重要なんです。サービスではなかなかリンクは出てこないですね。やると、実はさらに良いシステムを作っていけるんじゃないのかなと思います。サービスを使う場合、起動するメソッド名の情報をリクエストに含めたりします。全体を考えた際にリソースに対する処理インターフェースが統一できません。(もちろん、命名規約で縛ることも可能ですが。全体でリソースに対する操作を行うインターフェースを統一しようというスタイルが提案されました。メソッド(GET、PUT、POST、DELETE)になります。GETリソースを取得するメソッドです。メソッドはサーバの状態を変更しない用途で使用します。(厳密には副作用があってもよいとされています。よる副作用がありますが、クライアントに責任はなく、甚大な被害があるわけではないので問題ないとされています。)PUT主に、リソースの状態を変更する際に使うメソッドです。リソースの新規作成にも使われることがあります。PUTはべき等性を持ちます。Informationべき等性とは、何度同じリクエストを繰り返し実行しても同じ結果であることを意味する数学用語です。POSTリソースの新規作成の際に使うメソッドです。POSTのみが有効なメソッドとして処理されています。汎用的な処理として使われることが多くあります。リソースの新規作成でのみ使うことがよいとされています。サポートされていないため、このような現状は仕方ないといえるかと思います。新規作成以外の意味を持たせて使うことを、オーバーロードPOSTと呼びます。次のような違いがあります。サーバが決定するDELETEリソースの削除を行う際に使うメソッドです。DELETEもべき等性を持ちます。Web系の方が強いですがスマホアプリもできます。Webサービス開発やスマホアプリ開発案件あればお声がけください。