Mitologi istirahat

Perlengkapan

Beberapa teknologi dalam sejarah TI telah menghasilkan kontroversi sebanyak REST. Hal yang paling mengejutkan adalah bahwa para pihak yang bersengketa, sebagai suatu peraturan, sama sekali tidak mengetahui subjek sengketa.

Mari kita mulai dari awal. Roy Fielding, salah satu penulis spesifikasi HTTP dan URI, menyelesaikan PhD dalam Gaya Arsitektur dan Desain Arsitektur Perangkat Lunak Jaringan pada tahun 2000, bab kelima berjudul Representational State Transfer (REST). Disertasi tersedia di sini .

Seperti yang dapat Anda lihat dengan mudah dari bab ini, ini adalah gambaran abstrak yang cukup abstrak dari arsitektur jaringan terdistribusi yang tidak terikat dengan HTTP atau URL sama sekali. Selain itu, ini sama sekali bukan tentang aturan desain API; dalam bab ini, Fielding secara metodis mencantumkan kendala yang dihadapi oleh pengembang perangkat lunak jaringan terdistribusi. Di sini mereka:

• klien dan server tidak mengetahui struktur internal satu sama lain (arsitektur client-server);
• sesi disimpan di klien (desain stateless);
• data harus ditandai sebagai cacheable atau non-cacheable;
• antarmuka interaksi harus distandarisasi;
• sistem jaringan berlapis-lapis, mis. server hanya dapat menjadi proxy ke server lain;
• fungsionalitas klien dapat diperluas dengan menyediakan kode dari server.

Itu saja, definisi REST berakhir di sana. Selanjutnya, Fielding mengkonkretkan beberapa aspek implementasi sistem dalam batasan yang ditentukan, tetapi semuanya benar-benar abstrak dengan cara yang sama. Secara harfiah: “abstraksi informasi utama dalam REST adalah sumber daya; informasi apa pun yang dapat disebutkan namanya dapat menjadi sumber daya."

Pengambilan kunci dari definisi Fielding tentang REST sebenarnya adalah ini: perangkat lunak jaringan apa pun di dunia mengikuti prinsip REST , dengan pengecualian yang sangat, sangat jarang.

Memang:

• sangat sulit untuk membayangkan sebuah sistem di mana tidak akan ada setidaknya beberapa antarmuka interaksi standar, jika tidak, tidak mungkin untuk mengembangkannya;
• , , , , ;
• — , , ;
• , - - ;
• , 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 , , .

--

Ini adalah draf untuk bab selanjutnya dari buku tentang pengembangan API. Pekerjaan dilakukan di Github . Versi bahasa Inggris dari bab yang sama diterbitkan di media . Saya akan sangat menghargai jika Anda dapat membagikannya di reddit - Saya sendiri tidak dapat sesuai dengan kebijakan platform.