buy Latuda online overnight uk En el artculo anterior revisamos los mtodos HTTP mas usados para disear un api. En este caso vamos a estudiar las posibles respuestas (cdigos de estado) a dichas peticiones. Al igual que en el artculo anterior no vamos a ver todos los cdigos de estadode HTTP sino solo aquellos que nos sern de utilidad dentro de las apis.
200 Respuestas OK
- 200. Indica xito de la operacin. El mensaje de respuesta debe contener un cuerpo.
- 201. Secre o actualiz con xito un nuevo recurso web. En la respuesta se devuelve la URI del nuevo recurso creado dentro de la cabecera Location. La respuesta puede contener un cuerpo con los datos del nuevo recurso.
- 202. Indica que la peticin se ha aceptado pero que no est completa. Se usa para disear operaciones de larga duracin.
- 204. Indica xito de la operacin. El mensaje de respuesta debe estar vacio y no tener cuerpo.
http://modernsmile.com/about/meet-the-dentist/ El cdigo 200 y el 204 son iguales. La nica diferencia es que un 200 lleva cuerpo y el 204 no.
300 Redirecciones
- 301. Indica que el recurso se ha movido a otra URI de forma permanente.
- 304. Indica que el recurso no se ha modificado.Esta es la respuesta a una cache. Se pregunta si el recurso ha cambiado, y en funcin de la respuesta se vuelve a pedir o no.
400 Errores decliente
- 400. El servidor no entiende la peticin, por estar esta mal formada.
- 401.Acceso denegado: el recurso cbd products autorizacin. El usuario debe logarse para ver si puede acceder al recurso.
- 403. Acceso denegado: el servidor entiende la peticin, pero el usuario no tiene suficientes permisos para acceder. La peticin no debe repetirse.
- 404. Recurso no encontrado.
- 405. Mtodo no soportado. El recurso solicitado no soporta la accin pedida. En la respuesta se incluirn las acciones soportadas por el recurso en la cabecera “Allow”.
- 406. La peticin no es aceptable. Normalmente, se produce porque el servidor no soporta los tiposMIME aceptados por el cliente.
- 408. Timeout. Pues eso, se ha producido un timeout y se debe repetir la peticin exactamente igual pasado un tiempo.
- 409. Conflicto. El estado del recurso hace que no se pueda realizar la peticin. El cliente debe modificar la peticin y repetirla.
- 412. Fallo en la precondicin.Muy parecido al anterior.
- 415. El tipo mime del cuerpo de la peticin no est soportado por el servidor.
- 422. El cuerpo de la peticin est mal formado. Est mal el cuerpo de la peticin. Por ejemplo, si es XML o JSON y no cumplen con la estructura necesaria, o cualquier problema similar.
500 Error de servidor
- 500. Se produjo un error en el servidor. Cualquier error producido en la aplicacin del servidor saldr por aqu.
Este sera el resumen de todos los estados que usaremos a la hora de disear un api REST. Conviene usar todos, para hacer el api lo mas intuitiva y fcilde usar. Por supuesto que podemos hacer lo que nos de la gana (he visto apis que siempre devuelven 200 ante cualquier peticin y/o error pero evidentemente no es intuitivo y vuelve loco a cualquiera que intente interactuar con ella).
Lo suyo es pensar muy bien el api, porque ser lo que permanezca en el tiempo: tanto la implementacin del front, como la del back cambiarn, pero el interfaz con el que se comuniquen, no.
