Mitologia REST

Material

Poucas tecnologias na história da TI geraram tanta controvérsia quanto REST. O mais surpreendente é que as partes litigantes, via de regra, não têm absolutamente nenhuma idéia do objeto da disputa.

Vamos começar do início. Roy Fielding, um co-autor das especificações HTTP e URI, completou seu PhD em Estilos de Arquitetura e Design de Arquitetura de Software de Rede em 2000, o quinto capítulo do qual foi intitulado Representational State Transfer (REST). A dissertação está disponível aqui .

Como você pode ver facilmente neste capítulo, é uma visão geral bastante abstrata de uma arquitetura de rede distribuída que não está ligada a HTTP ou URLs de forma alguma. Além disso, não se trata de regras de design de API; neste capítulo, Fielding lista metodicamente as restrições enfrentadas por um desenvolvedor de software de rede distribuída. Aqui estão eles:

• cliente e servidor não conhecem a estrutura interna um do outro (arquitetura cliente-servidor);
• a sessão é armazenada no cliente (design sem estado);
• os dados devem ser marcados como armazenáveis ​​em cache ou não armazenáveis ​​em cache;
• as interfaces de interação devem ser padronizadas;
• os sistemas de rede são multicamadas, ou seja, o servidor só pode ser um proxy para outros servidores;
• a funcionalidade do cliente pode ser estendida fornecendo o código do servidor.

É isso, a definição de REST termina aí. Além disso, Fielding concretiza alguns aspectos da implementação de sistemas nas restrições especificadas, mas todos eles são completamente abstratos da mesma maneira. Literalmente: “a abstração de informações-chave em REST é um recurso; qualquer informação que possa ser nomeada pode ser um recurso. "

A principal lição da definição de REST de Fielding é, na verdade, esta: qualquer software de rede no mundo segue os princípios de REST , com raras exceções.

De fato:

• é muito difícil imaginar um sistema em que não houvesse pelo menos alguma interface de interação padronizada, caso contrário, seria simplesmente impossível desenvolvê-la;
• , , , , ;
• — , , ;
• , - - ;
• , 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 é um rascunho para um capítulo futuro do livro sobre desenvolvimento de API. O trabalho é feito no Github . A versão em inglês do mesmo capítulo é publicada na mídia . Eu agradeceria se você pudesse compartilhar no reddit - eu mesmo não posso de acordo com a política da plataforma.