Anteturilor și parametrii serviciului REST

Ultima postare

Postări: 226

Veronica

Admin

Topic starter

sept. 30, 2021 6:19 pm

(@veronica)

Estimable Member

S-a alăturat: 3 ani în urmă

Anteturilor și parametrii serviciului REST

Anteturile și parametrii REST conțin o multitudine de informații care vă pot ajuta să depistați problemele atunci când le întâlniți. Anteturile HTTP sunt o parte importantă a cererii și răspunsului API, deoarece reprezintă metadatele asociate cererii și răspunsului API. Anteturile transportă informații pentru:

Cerere și răspuns

Solicitați autorizarea

Cache de răspuns

Cookie-uri de răspuns

În afară de categoriile de mai sus, anteturile HTTP poartă, de asemenea, o mulțime de alte informații despre tipurile de conexiuni HTTP, proxy etc. Majoritatea acestor anteturi sunt pentru gestionarea conexiunilor dintre client, server și proxy și nu necesită validare explicită prin testare.

Anteturile sunt în mare parte clasificate ca anteturi de solicitare și anteturi de răspuns, cunosc principalele anteturi de cerere și răspuns. Va trebui să setați anteturile cererii atunci când trimiteți cererea pentru testarea unui API și va trebui să setați afirmația împotriva antetelor de răspuns pentru a vă asigura că anteturile corecte sunt returnate.

Anteturile pe care le veți întâlni cel mai mult în timpul testării API sunt următoarele, poate fi necesar să setați valori pentru acestea sau să setați afirmații împotriva acestor anteturi pentru a vă asigura că transmit informațiile corecte și totul funcționează bine în API:

Autorizare: transportă acreditări care conțin informațiile de autentificare ale clientului pentru resursa solicitată.
WWW-Authenticate: Acesta este trimis de server dacă are nevoie de o formă de autentificare înainte de a putea răspunde cu solicitarea resursei efective. Adesea trimis împreună cu un cod de răspuns 401, ceea ce înseamnă „neautorizat”.
Accept-Charset: Acesta este un antet care este setat odată cu cererea și îi spune serverului despre ce seturi de caractere sunt acceptabile de către client.
Content-Type: indică tipul de suport (text / html sau text / JSON) al răspunsului trimis clientului de către server, acest lucru îl va ajuta pe client să proceseze corect corpul răspunsului.
Cache-Control: Aceasta este politica cache definită de server pentru acest răspuns, un răspuns cache poate fi stocat de client și reutilizat până la ora definită de antetul Cache-Control.

Parametrii REST specifică părțile variabile ale resurselor dvs.: datele cu care lucrați. Înțelegerea metodelor de solicitare REST și SOAP, într-o cerere REST resursa cu care lucrați este specificată în URL - Uniform Resource Locator. Adresa URL este un caz special al URI - Uniform Resource Identifier - care constă din patru părți:

nume_schemă: parte_ierarhică? interogare # fragment

Pentru toate apelurile REST, numele schemei va fi întotdeauna „http:” sau „https:” dacă este trimis pe un canal securizat.

Resurse RESTful

În orice serviciu RESTful este foarte de dorit să aveți toate resursele structurate în funcție de ierarhia lor. Acestea sunt apoi specificate în partea ierarhică a adresei URL. Părțile ierarhice sunt toate 1) obligatorii și 2) unice. Aceasta înseamnă că niciunul dintre ele nu poate fi omis și toate pot apărea o singură dată. Anumite părți ale adresei URL vor fi remediate (cum ar fi numele serverului, portul și punctul final) și anumite părți vor fi parametrizate. Părțile parametrizate sunt adesea notate în cod și în documentație prin acolade.

Un serviciu web pentru comandarea cărților: Datele dvs. pot fi organizate în clienți, care conțin comenzi, care la rândul lor conțin cărți individuale. Adresa URL a resursei ar putea arăta astfel:

http: //server.test: 8080 / order_api / {customer_id} / {order_id} / {book_id}

Trimiterea unei solicitări DELETE către această adresă URL ar putea elimina o carte dintr-o comandă existentă, în timp ce trimiterea unei solicitări GET către această adresă URL ar putea prelua detaliile unei anumite cărți (cum ar fi dacă este în ordine sau în afara stocului).

Alternativ, un motor de rezervare a companiilor aeriene ar putea structura datele mai întâi cu avionul, care la rândul său ar putea conține clienți. Adresa URL ar putea arăta astfel:

https: //airline.server.test/ticketing_api/ {flight_id} / {customer_id}

Pentru o companie aeriană zborul (companiile aeriene se referă la zboruri specifice ca „coadă”) este obiectul mai mare de care trebuie să țină evidența, care conține apoi clienți (pasageri). În timp ce în exemplul anterior, într-adevăr nu există un obiect într-o librărie care să conțină clienți.

Parametrii de interogare sunt uneori denumiți parametri opționali; aceasta este prima trăsătură distinctivă de parametrii ierarhici: toate sunt opționale. A doua caracteristică este că nu sunt unice, ceea ce înseamnă că puteți specifica oricare parametru de mai multe ori. Parametrii de interogare sunt separați de parametrii ierarhici prin semnul întrebării. Sintaxa exactă a parametrilor actuali nu este definită în mod generic, dar în mod normal sunt o secvență de perechi cheie-valoare (separate printr-un semn egal), cu secvența separată fie printr-un punct și virgulă, fie printr-un semn cu semen.

Bazându-ne pe exemplul companiei aeriene de mai sus. Un client, atunci când face o rezervare, poate dori să adauge opțiuni, cum ar fi masa vegetariană și accesul pentru scaune cu rotile. Adresa URL a acestei resurse ar putea arăta astfel:

https: //airline.server.test/ticketing_api/ {flight_id} / {passenger_id}? option = vegetarian & option = scaun cu rotile

Parametrii fragmentului

Partea fragment a adresei URL, totul după un simbol hash, este o informație care este utilizată în mod normal numai de client, cum ar fi un browser, și nu este procesată de server. Prin urmare, este neinteresant atunci când se discută parametrii REST. Singurul element interesant este dacă trebuie să trimiteți caracterul hash real ca valoare (în loc să reprezentați simbolul de control hash) la una dintre opțiuni. În acest caz, trebuie să codificați adresa URL.

Codificarea caracterelor

Caracterele speciale sunt codificate în URL, printr-un mecanism numit „codare procentuală”. În acest mecanism, orice caracter poate fi înlocuit cu simbolul procentual, urmat de o valoare hexazecimală din două cifre a caracterului codificat. Dacă trebuie trimise caractere speciale (cum ar fi caracterul hash) ca date reale, acestea trebuie codificate. Toate celelalte caractere pot fi opțional codificate.

Limite de dimensiune

Deși standardul URI nu specifică o dimensiune maximă a adresei URL, majoritatea clienților aplică o limită arbitrară de 2000 de caractere. Trimiterea de date care este dificil de exprimat într-o manieră ierarhică și, în special, date care depășesc această limită de 2000 de caractere, ar trebui transmise în corpul cererii. După cum sa discutat în SOAP vs.REST, datele din corp pot fi structurate în orice format lizibil de mașină, dar cel mai adesea sunt structurate ca XML sau JSON.