Clever Geek Handbook

REST mythologie

Matériel



Peu de technologies dans l'histoire de l'informatique ont suscité autant de controverse que REST. Le plus surprenant est que les parties au litige n'ont en règle générale aucune idée de l'objet du litige.







Commençons par le tout début. Roy Fielding, co-auteur des spécifications HTTP et URI, a obtenu son doctorat en styles architecturaux et conception d'architecture logicielle réseau en 2000, dont le cinquième chapitre était intitulé Representational State Transfer (REST). La thèse est disponible ici .







Comme vous pouvez facilement le voir dans ce chapitre, il s'agit d'un aperçu assez abstrait d'une architecture de réseau distribué qui n'est pas du tout liée à HTTP ou aux URL. De plus, il ne s'agit pas du tout de règles de conception d'API ; dans ce chapitre, Fielding répertorie méthodiquement les contraintes rencontrées par un développeur de logiciels de réseau distribué. Les voici:







  • client et serveur ne connaissent pas la structure interne de l'autre (architecture client-serveur) ;
  • la session est stockée sur le client (conception sans état) ;
  • les données doivent être marquées comme pouvant ou non être mises en cache ;
  • les interfaces d'interaction devraient être normalisées;
  • les systèmes de réseau sont multicouches, c'est-à-dire le serveur ne peut être qu'un proxy vers d'autres serveurs ;
  • les fonctionnalités du client peuvent être étendues en fournissant le code du serveur.


Ça y est, la définition de REST s'arrête là. De plus, Fielding concrétise certains aspects de la mise en œuvre des systèmes dans les contraintes spécifiées, mais ils sont tous complètement abstraits de la même manière. Littéralement : « l'abstraction des informations clés dans REST est une ressource ; toute information pouvant être nommée peut être une ressource."







La principale conclusion à retenir de la définition de Fielding de REST est en fait la suivante : tout logiciel de réseau dans le monde suit les principes de REST , à de très, très rares exceptions près.







En effet:







  • il est très difficile d'imaginer un système dans lequel il n'y aurait pas au moins une interface d'interaction standardisée, sinon il sera tout simplement impossible de le développer ;
  • , , , , ;
  • — , , ;
  • , - - ;
  • , 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 , , .







--







Ceci est un brouillon pour un futur chapitre du livre sur le développement d'API. Le travail se fait sur Github . La version anglaise du même chapitre est publiée sur le support . J'apprécierais si vous pouviez le partager sur reddit - je ne peux pas moi-même selon la politique de la plate-forme.







More articles:


All Articles