REST神話

物資



IT の歴史の中で、REST ほど多くの論争を引き起こしたテクノロジーはほとんどありません。最も驚くべきことは、紛争当事者は、原則として、紛争の主題についてまったく考えていないということです。







最初から始めましょう。HTTP および URI 仕様の共著者である Roy Fielding は、2000 年にネットワーク ソフトウェア アーキテクチャのアーキテクチャ スタイルと設計の博士号を取得しました。その第 5 章のタイトルは Representational State Transfer (REST) です。論文はこちらから入手できます







この章から簡単にわかるように、これは分散ネットワーク アーキテクチャのかなり抽象的な概要であり、HTTP や URL にまったく関連付けられていません。さらに、これは API 設計ルールに関するものではありません。この章では、Fielding が分散型ネットワーク ソフトウェア開発者が直面する制約を系統的にリストしています。はい、どうぞ:







  • クライアントとサーバーは、互いの内部構造を認識しません (クライアント サーバー アーキテクチャ)。
  • セッションはクライアントに保存されます (ステートレス設計)。
  • データはキャッシュ可能またはキャッシュ不可としてマークする必要があります。
  • 相互作用インターフェースは標準化する必要があります。
  • ネットワーク システムは多層構造です。サーバーは他のサーバーへのプロキシとしてのみ使用できます。
  • サーバーからコードを提供することで、クライアントの機能を拡張できます。


これで REST の定義は終わりです。さらに、Fielding は、指定された制約の中でシステムの実装のいくつかの側面を具体化しますが、それらはすべて同じように完全に抽象的です。文字通り、「REST における重要な情報の抽象化はリソースです。名前を付けることができる情報はすべてリソースになることができます。」







Fielding の REST の定義から得られる重要なポイントは、実際にはこれです。世界中のネットワーク ソフトウェアは、非常にまれな例外を除いて、REST の原則に従っています。







確かに:







  • 少なくとも標準化された相互作用インターフェースが存在しないシステムを想像することは非常に困難です。そうでなければ、それを開発することは単に不可能です。
  • , , , , ;
  • — , , ;
  • , - - ;
  • , code-on-demand , , , «» , — .


, , , . , , REST . , , code-on-demand — , . S («stateless»), , , . (, , : « … , - ».)







, , 2008 , . , , :







  • REST API ;
  • REST API , ; ;
  • REST API , .


, REST , , - REST API, API, , API.







, , , REST -2008.







REST



, ; : , ( ), . REST HTTP URL «RESTful API», .







, REST ? . , , , .







, , API - , - «» API. , 2000 , , .







«» REST- API (, )? , — .







REST , : , , ( RESTful- !).







HTTP : , , :







  • URL , - ;
  • , ; — , ( ), - , ;
  • , ; , , ;
  • , , , , .


, , — .







? ( ) . - , ; API , , , API . (, HTTP-) , , , , ; , , , -, , . HTTP-, , . - , — .







( , , . , Accept-Encoding Content-Length .)







, REST-, . stateless-: , .







. . . , :







//  
GET /me
Cookie: session_id=< >
//  
GET /delete-me
Cookie: session_id=< >
      
      





?







  1. ; /me , ; , .
  2. , .. ; .


, , , URL:







//  
GET /me?session_id=< >
//  
GET /delete-me?session_id=< >
      
      





, ( , ), :







  1. URL , ; , , .. URL .
  2. . , , , - .


REST? :







//  
GET /user/{user_id}
Authorization: Bearer <token>
//  
DELETE /user/{user_id}
Authorization: Bearer <token>
      
      





URL , , ; , .. . DELETE-; , Authorization .







, : -, , Authorization (, , ). , , . , : , , , URL, , , GET /user/{user_id}/public-profile



/public-profile



URL, . REST.







. , DELETE /user/{user_id}



. ?







1. HTML- , -, , , . - . , - — , - 200 — , , .







2. - HTTP-, , 504, , , , - , , . , , — , 504.







3. , , DELETE



, ; — 1 2. , ( , DELETE



), : . «» - , .







, (3) , (1) (2): . , , ; (3) (1) (2): . , , . , , ( , ) .







, ( ) : - «», , . - — , , .







, , . -, , - , .







/ / HTTP, . , -, . -, . , , , - .







, « REST API», , , :







  1. « URL , » — , - . URL :







    • URL ;
    • , URL — , .


  2. « HTTP- , » — . , (), (), () ; , , - — , . : , DELETE /list?element_index=3



    , .. , DELETE



    ;







  3. « POST



    , GET



    , PUT



    , PATCH



    DELETE



    » — , « » , . , , - - «» «»:







    • GET



      API , ; Cache-Control



      no-cache



      POST



      ; , - ;
    • , — PUT



      (, );
    • PATCH



      , PUT



      ;
    • , — , PUT /archive?entity_id



      .


  4. « » — , , .







  5. « », « URL» , REST.









, REST API:







  1. HTTP, , .
  2. URL .
  3. , URL (, , query-), .
  4. HTTP- API , , : , .


REST



, REST — , , API-, - — , , , , — - . , , , REST .







REST , , API-, - — , , , , — . , HTTP , REST — , — , . - .







REST — : , — . , .







REST



- REST -2008, , , HATEOAS. , , : , , , , . , , , API , , .







, , API . , ; — . API , , ( ) . , , API , , API - .







, - , API , , .







--







これは、API 開発に関する本の将来の章のドラフトです。作業はGithubで行わます。同章の英語版がmedium に掲載されています。reddit で共有していただけるとありがたいです - 私自身はプラットフォームのポリシーに従ってできません。








All Articles