rest api response codes
En aquest tutorial, coneixerem els diferents codis de resposta REST, els tipus de sol·licituds REST i algunes pràctiques recomanades a seguir. :
Al tutorial anterior, REST API Architecture and Constraints, hem après sobre serveis web, REST Architecture, POSTMAN, etc.
Podem consultar el primer tutorial de l'API REST per obtenir més informació al respecte.
Sempre que cerqueu alguna paraula o frase en un motor de cerca, aquest envia la sol·licitud al servidor web. El servidor web retorna un codi de resposta de tres dígits que indica l'estat de la sol·licitud.
Què aprendreu:
- Resta els codis de resposta de l'API
- Diferents tipus de sol·licituds REST
- Pràctiques recomanades mentre es valida una API REST
- Conclusió
Resta els codis de resposta de l'API
A continuació, es mostren alguns exemples de codis de resposta que normalment veurem mentre realitzem proves REST API a través de POSTMAN o a través de qualsevol client API REST.
# 1) Sèrie 100
Són respostes temporals
- 100 Continua
- 101 Protocols de commutació
- 102 Processament
# 2) Sèrie 200
El client accepta la sol·licitud i es processa amb èxit al servidor.
proves de serveis web mitjançant preguntes d’entrevistes soapui
- 200 - D'acord
- 201 - Creat
- 202 - Acceptat
- 203 - Informació no autoritzada
- 204 - Sense contingut
- 205 - Restableix el contingut
- 206 - Contingut parcial
- 207 - Multi-Estat
- 208 - Ja s'ha informat
- 226 - IM utilitzat
# 3) Sèrie 300
La majoria dels codis relacionats amb aquesta sèrie són per a la redirecció d’URL.
- 300 - Múltiples opcions
- 301 - Mogut permanentment
- 302 - Trobat
- 303 - Marqueu Altres
- 304 - No modificat
- 305: utilitzeu el servidor intermediari
- 306: canvia el servidor intermediari
- 307 - Redirecció temporal
- 308 - Redirecció permanent
# 4) Sèrie 400
Són específics de l’error del client.
- 400 - Sol·licitud incorrecta
- 401 - No autoritzat
- 402 - Es requereix pagament
- 403 Prohibit
- 404 No trobat
- 405 - Mètode no permès
- 406 - No s’accepta
- 407 - Cal autenticació de servidor intermediari
- 408 - Temps d'espera de la sol·licitud
- 409 - Conflicte
- 410 - Desaparegut
- 411 - Longitud requerida
- 412 - Ha fallat la condició prèvia
- 413: càrrega útil massa gran
- 414 - URI massa llarg
- 415 - Tipus de suport no admès
- 416 - Gamma no satisfactòria
- 417 - L'expectativa ha fallat
- 418 - Sóc una tetera
- 421 - Sol·licitud incorrecta
- 422 - Entitat no processable
- 423 - Bloquejat
- 424: dependència fallida
- 426 - Es requereix actualització
- 428 - Requisit previ
- 429 - Massa sol·licituds
- 431 - Sol·liciteu els camps de la capçalera massa grans
- 451 - No disponible per motius legals
# 5) Sèrie 500
Són específics de l’error del servidor.
- 500 - Error intern del servidor
- 501 - No implementat
- 502 Porta d'enllaç no vàlida
- 503 Servei no disponible
- 504 - Temps d'espera de la passarel·la
- 505 - La versió HTTP no és compatible
- 506: la variant també es negocia
- 507 - Emmagatzematge insuficient
- 508 - Bucle detectat
- 510 - No ampliat
- 511 - Cal autenticació de xarxa
A part d'això, hi ha diversos codis diferents que existeixen, però ens desviaran de la nostra discussió actual.
Diferents tipus de sol·licituds REST
Aquí analitzarem tots i cadascun dels mètodes de l'API REST juntament amb les col·leccions.
Mètode | Descripció |
---|---|
PATCH | Molt semblant a la frase, però s’assembla més a una manipulació menor del contingut dels recursos |
ACONSEGUIR | Recupera la línia d'estat, cos de resposta, capçalera, etc. |
CAP | Igual que GET, però només obté la línia d'estat i la secció de capçalera |
POST | Realitzeu la sol·licitud mitjançant la càrrega útil de la sol·licitud, principalment en la creació d'un registre al servidor |
POSA | Útil per manipular / actualitzar el recurs mitjançant Sol·licitud de càrrega útil |
ESBORRAR | Suprimeix la informació relacionada amb el recurs objectiu. |
OPCIONS | Descriviu les opcions de comunicació del recurs objectiu |
Nota: Hi ha tants mètodes que podem fer amb POSTMAN, però només parlarem dels mètodes següents utilitzant POSTMAN.
Utilitzarem un URL fictici per demostrar-ho http://jsonplaceholder.typicode.com . Aquest URL ens proporcionarà les respostes desitjades, però no hi haurà cap modificació al servidor.
# 1) ACONSEGUEIX-TE
Paràmetres de sol·licitud:
Mètode: GET
Sol·licita un URI: http://jsonplaceholder.typicode.com/posts
Paràmetre de consulta: id = 3;
Resposta rebuda:
Codi d'estat de resposta: 200 D'acord
Cos de resposta :
# 2) CAP
Paràmetres de sol·licitud:
Mètode: CAP
Sol·licita un URI: http://jsonplaceholder.typicode.com/posts
# 3) POST
# 4) POSAR
# 5) OPCIONS
Paràmetres de sol·licitud:
Mètode: OPCIONS
Sol·licita un URI: http://jsonplaceholder.typicode.com/
Capçaleres: Content-type = Application / JSON
Preguntes i respostes de l'entrevista j2ee per a desenvolupadors sèniors
# 6) PATCH
Pràctiques recomanades mentre es valida una API REST
# 1) Operacions CRUD
Consta de 4 mètodes mínims proporcionats i haurien de funcionar a l'API web.
OBTENIR, POSTAR, POSAR i ESBORRAR.
# 2) Gestió d'errors
Possibles suggeriments per als consumidors de l'API sobre l'error i per què s'ha produït. També hauria de proporcionar missatges d'error de nivell granular.
# 3) Versió de l'API
Utilitzeu la lletra 'v' a l'URL per indicar la versió de l'API. Per exemple-
http://restapi.com/api/v3/passed/319
Paràmetre addicional al final de l'URL
http://restapi.com/api/user/invaiiduser?v=6.0
# 4) Filtratge
Si voleu especificar l'usuari, seleccioneu les dades desitjades en lloc de proporcionar-les totes alhora.
/ contacte / sam? nom, edat, designació, oficina
/ contacts? limit = 25 & offset = 20
# 5) Seguretat
Marca de temps en totes les sol·licituds i respostes de l'API. Ús de access_token per assegurar-vos que les parts de confiança invocen l'API.
es diuen mètodes python que s’utilitzen per afegir elements a una llista o eliminar-los d’una llista
# 6) Analítica
Tenir Analytics a l’API REST us proporcionarà una bona visió de l’API que s’està provant, especialment quan el nombre de registres obtinguts és molt alt.
# 7) Documentació
S'ha de proporcionar documentació adequada perquè els consumidors d'API puguin utilitzar-la i consumir els serveis amb eficàcia.
# 8) Estructura d'URL
L’estructura d’URL hauria de ser senzilla i l’usuari hauria de poder llegir el nom de domini fàcilment.
Per exemple , https://api.testdomain.com.
Les operacions que es realitzin amb l'API Rest també haurien de ser molt fàcils d'entendre i realitzar.
Per exemple, per a un client de correu electrònic:
ACONSEGUIR: read / inbox / messages: recupera la llista de tots els missatges a la safata d’entrada
ACONSEGUIR: read / inbox / messages / 10 - Lectures 10thmissatge a la safata d’entrada
POST: create / inbox / folders: creeu una carpeta nova a la safata d'entrada
ELIMINA: Suprimeix / correu brossa / missatges: elimineu tots els missatges de la carpeta de correu brossa
POSA: carpetes / safata d'entrada / subcarpeta: actualitzeu la informació relativa a la subcarpeta a la safata d'entrada.
Conclusió
Moltes organitzacions prefereixen implementar l'API web REST, ja que és molt fàcil d'implementar, té normes i regles inferiors a seguir, fàcil d'accés, lleuger i fàcil d'entendre. POSTMAN té els seus avantatges quan s’utilitza amb l’API RESTful gràcies a la seva interfície d’usuari fàcil d’utilitzar, la facilitat d’ús i de prova, la velocitat de resposta més ràpida i la nova funció RUNNER.
Al següent tutorial d’aquesta sèrie Tutorial de l’API Rest, automatitzarem els casos de prova que hem executat manualment.
Lectura recomanada
- Com automatitzar les sol·licituds d'API mitjançant Rest Assured i Jenkins
- Proves de l'API REST amb cogombre mitjançant l'enfocament BDD
- 10 millors eines de proves d'API el 2021 (eines de proves d'API SOAP i REST)
- Proves API REST amb Spring RestTemplate i TestNG
- Com es crea un projecte REST a SoapUI Pro: tutorial núm. 13
- Treballar amb sol·licituds HTTP a JMeter
- Tipus de riscos en projectes de programari
- Diferència de SOAP Vs REST: comparació de rendiment i seguretat