Clever Geek Handbook

Descanso mitologĂ­a

Material bélico



Pocas tecnologías en la historia de la TI han generado tanta controversia como REST. Lo más sorprendente es que las partes contendientes, por regla general, no tienen ni idea del tema de la disputa.







Empecemos desde el principio. Roy Fielding, coautor de las especificaciones HTTP y URI, completó su doctorado en Estilos arquitectónicos y diseño de arquitectura de software de red en 2000, cuyo quinto capítulo se tituló Transferencia de estado representacional (REST). La disertación está disponible aquí .







Como puede ver fácilmente en este capítulo, es una descripción general bastante abstracta de una arquitectura de red distribuida que no está ligada a HTTP o URL en absoluto. Además, no se trata en absoluto de reglas de diseño de API; En este capítulo, Fielding enumera metódicamente las limitaciones que enfrenta un desarrollador de software de red distribuida. Aquí están:







  • el cliente y el servidor no conocen la estructura interna del otro (arquitectura cliente-servidor);
  • la sesiĂłn se almacena en el cliente (diseño sin estado);
  • los datos deben marcarse como almacenables en cachĂ© o no almacenables en cachĂ©;
  • las interfaces de interacciĂłn deberĂ­an estar estandarizadas;
  • Los sistemas de red son de varias capas, es decir el servidor solo puede ser un proxy para otros servidores;
  • la funcionalidad del cliente se puede ampliar proporcionando el cĂłdigo desde el servidor.


Eso es todo, la definición de REST termina ahí. Además, Fielding concretiza algunos aspectos de la implementación de sistemas en las restricciones especificadas, pero todos son completamente abstractos de la misma manera. Literalmente: “la abstracción de información clave en REST es un recurso; cualquier información que se pueda nombrar puede ser un recurso ".







La conclusiĂłn clave de la definiciĂłn de REST de Fielding es en realidad la siguiente: cualquier software de red en el mundo sigue los principios de REST , con muy, muy raras excepciones.







En efecto:







  • es muy difĂ­cil imaginar un sistema en el que no habrĂ­a al menos alguna interfaz de interacciĂłn estandarizada, de lo contrario, simplemente será imposible desarrollarlo;
  • , , , , ;
  • — , , ;
  • , - - ;
  • , 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 , , .







--







Este es un borrador para un capítulo futuro del libro sobre desarrollo de API. El trabajo se realiza en Github . La versión en inglés del mismo capítulo se publica en medium . Le agradecería si pudiera compartirlo en reddit; yo mismo no puedo según la política de la plataforma.







More articles:


All Articles