REpresentational State Transfer

WEBとhttp 1.0の入門と機能開発について、Roy T.Fieldingに問題があります.
「既存のWebを破壊せずにHTTP機能を追加する方法」
当時の仕様が発表されるまでは、すべての人がWebとHTTPプロトコルを使用していたため、サブバージョンを破壊することなく機能を追加する方法が必要であり、RESTの設計方法を記述した論文がある.

RESTのスタイルの設定

1) Client - Server

클라이언트는 서버에 요청을 보내고 응답 대기
서버가 요청에 대한 결과를 만들어서 응답

ビジネスロジックとデータをサーバに配置し、クライアントがUIのみを担当できるようにすることで、お互いに促進することができます.サーバ(固定されたクライアントとサーバ)ではなく、リクエストを送信する側がクライアントである場合、リクエストを受信して応答する側がサーバであることが便利です.

2) Stateless

つながるStatefulとは?
サーバが途中で変更された場合、すぐにエラーが発生するため、サーバはクライアントの状態を維持しながら応答します.
欠点は、サーバを交換できないことです.

A. 클라이언트  => 제육 주세요 => 서버
B. 클라이언트  <= 몇인분 줄까요? <= 서버 (제육)
C. 클라이언트  => 2인분 주세요 => 서버 (제육 + 2인분)
    *C. 만약 여기서 서버가 바뀌었다면?
    *D. 클라이언트  <= 뭘 2인분 달라고요? <= 서버
    *A. 클라이언트는 다시 결제 과정을 반복해야된다.

D. 클라이언트  <= 제육 2인분 보냅니다 <= 서버

推測を表すStatelessとは?
サーバは途中で変更された場合、自分でメンテナンスしないため、クライアントのステータスを保持して応答しません.
サーバを無限に追加

A. 클라이언트  => 제육 2인분 주세요 => 서버
    *A. 애초에 클라이언트가 필요한 정보를 다 보내기 때문에
    서버가 아무리 바뀐들 지장이 없다.

B. 클라이언트  <= 제육 2인분 보냅니다 <= 서버

わかりません.ステータス制限なし

ステータス設計なし.

ログイン不要の簡易サービスログイン画面

毎回必要な情報はクライアントに送信されるので重いです.

ステータスを保持するように設計

ログインユーザがサーバにログインした状態を維持

通常はブラウザCookie、サーバセッションなどを使用してステータスを保持します

ただし、少なくとも「ステータスを保持」を使用します.

3) Cache

HTTPヘッダは、キャッシュおよび条件付き要求を処理することができる.wwwのように、クライアントは応答をキャッシュできる必要があります.

キャッシュがない場合

のデータが変わらなくても、ネットワークを通じてデータをダウンロードし続けます.

インターネットは非常に遅く、高価です.

低速ユーザー体験

キャッシュの適用

  HTTP/1.1 200 OK
  Content-Type: image/jpeg
  cache-control: max-age=60 //캐시가 유효한 시간

  asdjv212... // 이미지 파일 byte

ブラウザが応答結果を保存して再要求すると、キャッシュは有効な時間にクエリーされ、再使用されます.

4) Uniform Interface

統合設計リソース(すべてのリソース、uri、img、txtなど)が要求するアーキテクチャスタイル

リソースID:uriによってリソースを識別

リソースの操作を表す:HTTPメソッドのget、post、deleteなどの名前変更転送でリソースを操作する必要があります.

self-description message:どんなメッセージも自分で説明しなければなりません.

HTTP/1.1 200 OK
Host: www.example.org
Content-Type: application/json-patch+json

[ { "op": "remove", "path": "/a/b/c" } ]

Hypermedia as the Engine of Application State(HATEOAS):アプリケーションのステータスはHyperlinkで移行する必要があります.

HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel="previous",
            </articles/3>; rel="next";

{
    "title": "The second article",
    "contents": "blah blah..."
}

5) Layered Sysytem

これは、階層化されたアーキテクチャである必要があり、サーバがクライアントが知らないうちに柔軟な構造で開発できる必要があることを意味します.

6) Code-on-Demand(optional)

サーバは、クライアントにコードを送信して実行できるはずです.(javascript)

n/a.結論

RESTは長時間進化したWebアプリケーションのために設計された方式である.

は、統合リソース識別子(HTTP URI)によってリソース

を識別する.

HTTPメソッド(POST、GET、PUT、DELETE)

CRUDの対応するリソース(URI)に対する動作

を適用する.

RESTの6原則に従い、設計

HTTP 3.0が更新されると、ブラウザをこのバージョンに更新することなくWebを使用できます.また、新しいHTML specを追加しても、既存のhtmlファイルが実行できなくなることはありません.このようなWebの発展が可能になったのは,RESTという原則があったからである.