Panimula sa REST

8.1 Remote na diskarte sa API

Ang lahat ng mga programmer ay gumagawa ng parehong pagkakamali kapag bumubuo ng isang arkitektura ng client-server. Sinimulan nilang ituring ang mga kahilingan sa server bilang mga tawag sa pamamaraan .

Gusto mong simulan ang proseso ng pagbuo ng ulat sa server, bakit hindi magpadala ng kahilingan tulad ng:

http://server.com/startDocumentGeneration?params

At paano i-download ang ulat pagkatapos nitong makumpleto? Upang gawin ito, magsusulat kami ng isa pang pamamaraan:

http://server.com/getDocument

Ang server ay HttpSessionnag-iimbak ng impormasyon sa aming dokumento, at sa sandaling mabuo ang dokumento, ibabalik ito ng server.

Mahusay na diskarte. O hindi?

Grabe talaga ang approach. Ang bagay ay dapat tandaan ng server ang numero ng dokumento. Sa madaling salita, upang maayos na maproseso ang mga bagong tawag sa pamamaraan, dapat tandaan ng server ang mga resulta ng pagtawag sa mga nakaraang pamamaraan.

Sa web, ito ay isang malaking problema. Maaaring mawala ang Internet, maaaring isara ang browser. Ang pahina ay maaaring i-reload o aksidenteng na-click sa isang link, at iba pa. At ang server ay magpapatuloy na mag-imbak ng mga megabytes ng data mula sa mga nakaraang kahilingan ng gumagamit ...

Para sa kumportableng trabaho sa server, hindi mo maaaring asahan na palagi mong nasa kamay ang data ng mga nakaraang kahilingan sa server.

Paano pagkatapos tumawag sa mga pamamaraan ng server? Ang tamang sagot ay magiging kahila-hilakbot: hindi!

8.2 diskarte sa REST

Ang mga programmer ay bumalik sa mga pangunahing kaalaman at naalala na sa simula ang kahilingan ay naglalaman ng landas patungo sa file sa server:

http://server.com/path?params

At nagpasya kaming gamitin ang diskarte na ito sa maximum.

Ngayon ang server ay itinuturing bilang isang imbakan ng data na nakikita sa labas sa anyo ng isang puno .

Kung gusto mong makakuha ng listahan ng lahat ng user, tawagan ang query:

http://server.com/users

Kung gusto mong makakuha ng data sa user 113, patakbuhin ang query:

http://server.com/users/113

At iba pa, lahat sa parehong ugat.

Muli, ang server ay nakikita bilang isang imbakan ng data na nakikita sa labas sa anyo ng isang puno.

Maaaring matanggap ang data - KUMUHA ng mga kahilingan , binago - POST kahilingan at tanggalin - DELETE kahilingan .

8.3 Walang estado

Ang REST protocol ng pakikipag-ugnayan sa pagitan ng kliyente at ng server ay nangangailangan ng sumusunod na kondisyon: sa panahon sa pagitan ng mga kahilingan mula sa kliyente, walang impormasyon tungkol sa estado ng kliyente ang nakaimbak sa server.

Ang lahat ng mga kahilingan mula sa kliyente ay dapat gawin sa paraang natatanggap ng server ang lahat ng impormasyong kailangan nito upang matupad ang kahilingan sa bawat oras . Ang estado ng session ay nai-save sa panig ng kliyente.

Sa panahon ng pagproseso ng mga kahilingan ng kliyente, ang kliyente ay itinuturing na nasa isang transisyonal na estado. Ang bawat indibidwal na estado ng aplikasyon ay kinakatawan ng mga link na maaaring i-invoke sa susunod na pag-hit ng kliyente.

8.4 Pagkakapareho ng interface

Ang lahat ng mga landas na ginamit upang kunin ang mga bagay mula sa server ay na-standardize. Ito ay napaka-maginhawa, lalo na kung nakakakuha ka ng data mula sa iba pang mga REST server.

Lahat ng object interface ay dapat sumunod sa tatlong kundisyon:

Pagkilala sa mapagkukunan

Natutukoy ang lahat ng mapagkukunan sa mga kahilingan gamit ang isang URI. Ang mga mapagkukunan sa loob ng server ay hiwalay sa mga view na ibinalik sa mga kliyente. Halimbawa, ang isang server ay maaaring magpadala ng data mula sa isang database bilang HTML, XML, o JSON, alinman sa mga ito ay isang uri ng imbakan sa loob ng server.

Pagmamanipula ng Mga Mapagkukunan sa Pamamagitan ng View

Kung nag-iimbak ang kliyente ng representasyon ng mapagkukunan, kabilang ang metadata, mayroon itong sapat na impormasyon upang baguhin o tanggalin ang mapagkukunan sa server.

Mga mensaheng "naglalarawan sa sarili."

Ang bawat mensahe ay naglalaman ng sapat na impormasyon upang maunawaan kung paano ito pangasiwaan. Halimbawa, kung kailangan mo ng impormasyon tungkol sa user, ibabalik sa iyo ng server ang JSON object, kung saan magkakaroon ng pangalan, address field.

Hindi dapat magkaroon ng sitwasyon kung saan kailangang malaman ng kliyente na ang unang numero sa tugon ay ang edad, at ang pangalawa ay ang petsa ng kapanganakan.

8.5 Pag-cache

Ipinapalagay ng REST approach na ang mga kahilingan sa data ay ginagawa sa pamamagitan ng HTTP protocol. Samakatuwid, ang mga bagay ay nakuha sa pamamagitan ng pagtawag sa isang kahilingan sa GET. Nangangahulugan ito na sila, tulad ng lahat ng mga mapagkukunan na natanggap sa pamamagitan ng isang kahilingan sa GET, ay napapailalim sa lahat ng mga patakaran para sa pag-cache ng mga mapagkukunan ng HTTP.

Iyon ay, ang data na natanggap sa pamamagitan ng REST API ay naka-cache sa parehong paraan tulad ng anumang mga static na mapagkukunan sa mga web server. kagandahan :)