8.1 Remote API pendekatan
Kabeh programer nggawe kesalahan sing padha nalika mbangun arsitektur klien-server. Padha miwiti kanggo nambani panjalukan kanggo server minangka cara telpon .
Sampeyan pengin miwiti proses nggawe laporan ing server, kenapa ora ngirim panjaluk kaya:
http://server.com/startDocumentGeneration?paramsLan carane ndownload laporan sawise rampung? Kanggo nindakake iki, kita bakal nulis cara liyane:
http://server.com/getDocumentServer ing HttpSessionnyimpen informasi ing document kita, lan sanalika document kui, server bakal menehi maneh.
pendekatan gedhe. Utawa ora?
Pendekatane pancen elek. Bab iku server kudu ngelingi nomer dokumen. Ing tembung liya, supaya bisa ngolah panggilan metode anyar kanthi bener, server kudu ngelingi asil nelpon metode sadurunge.
Ing web, iki masalah gedhe. Internet bisa ilang, browser bisa ditutup. Kaca kasebut bisa dimuat maneh utawa ora sengaja diklik ing tautan, lan liya-liyane. Lan server bakal terus nyimpen megabyte data saka panjalukan pangguna sadurunge ...
Kanggo karya nyaman karo server, sampeyan ora bisa nyana yen sampeyan bakal tansah duwe data panjalukan sadurungé kanggo server ing tangan.
Kepiye carane nelpon metode server? Jawaban sing bener bakal elek: ora!
8.2 Pendekatan REST
Programer bali menyang dhasar lan eling yen panjaluk kasebut wiwitane ngemot path menyang file ing server:
http://server.com/path?paramsLan kita mutusake nggunakake pendekatan iki kanthi maksimal.
Saiki server dianggep minangka gudang data sing katon ing njaba ing wangun wit .
Yen sampeyan pengin entuk dhaptar kabeh pangguna, hubungi pitakon:
http://server.com/usersYen sampeyan pengin entuk data ing pangguna 113, bukak pitakon:
http://server.com/users/113Lan sateruse, kabeh ing urat sing padha.
Sepisan maneh, server katon minangka gudang data sing katon ing njaba ing wangun wit.
Data bisa ditampa - njaluk panjalukan , diowahi - POST request lan dibusak - DELETE request .
8.3 Ora ana negara
Protokol REST interaksi antarane klien lan server mbutuhake kondisi ing ngisor iki: sajrone periode antarane panjalukan saka klien, ora ana informasi babagan kahanan klien sing disimpen ing server.
Kabeh panjalukan saka klien kudu digawe kanthi cara sing server nampa kabeh informasi sing dibutuhake kanggo nepaki panjalukan saben wektu . Negara sesi disimpen ing sisih klien.
Sajrone pangolahan panjalukan klien, klien dianggep minangka negara transisi. Saben negara aplikasi individu diwakili dening pranala sing bisa dijaluk nalika klien tekan sabanjure.
8.4 Interface uniformity
Kabeh path sing digunakake kanggo njupuk obyek saka server wis standar. Iki trep banget, utamane yen sampeyan entuk data saka server REST liyane.
Kabeh antarmuka obyek kudu tundhuk karo telung syarat:
Identifikasi sumber daya
Kabeh sumber daya diidentifikasi ing panjalukan nggunakake URI. Sumber daya ing server kapisah saka tampilan sing bali menyang klien. Contone, server bisa ngirim data saka database minangka HTML, XML, utawa JSON, ora ana jinis panyimpenan ing server.
Manipulasi Sumber Daya Liwat Tampilan
Yen klien nyimpen perwakilan saka sumber, kalebu metadata, banjur duwe informasi sing cukup kanggo ngowahi utawa mbusak sumber ing server.
Pesen "nggambarake dhewe".
Saben pesen ngemot informasi sing cukup kanggo ngerti carane nangani. Contone, yen sampeyan butuh informasi babagan pangguna, banjur server bakal ngasilake obyek JSON, sing bakal ana jeneng, kolom alamat.
Mesthine ora ana kahanan ing ngendi klien kudu ngerti yen nomer pisanan ing respon yaiku umur, lan nomer loro yaiku tanggal lair.
8.5 Caching
Pendekatan REST nganggep yen panjalukan data digawe liwat protokol HTTP. Mulane, obyek dipikolehi kanthi nelpon panyuwunan GET. Iki tegese, kaya kabeh sumber daya sing ditampa liwat panyuwunan GET, tundhuk kabeh aturan kanggo cache sumber HTTP.
Yaiku, data sing ditampa liwat REST API di-cache kanthi cara sing padha karo sumber daya statis ing server web. ayu :)