Developer Experience
6
min de lectura
23 de julio de 2020

Buenas prácticas: HTTP Status

Luciana Bandeira
Developer Experience
Ayudo a los desarrolladores con onboarding y las mejores prácticas de la API para garantizar la mejor Developer Experience . En mi tiempo libre me dedico a los libros, a investigar (y probar) postres y me apasiona viajar.
Más sobre el autor

Hay algunas buenas prácticas y acciones que nuestro equipo de DX recomienda a los clientes que utilizan las API para ponerlas en práctica con el fin de simplificar la comprensión de los desarrolladores durante el uso.

De hecho, estas buenas prácticas también pueden aplicarse en el Portal del Desarrollador, para apoyar y guiar al desarrollador en este proceso de uso.

Diariamente, uno de los elementos que hemos visto que facilitan la comunicación y la comprensión para el desarrollo en el consumo de los API es el uso correcto de HTTP Status.

La normalización de los códigos de retorno que proporcionará la API ayudará al desarrollador y al proceso de integración, así como al desarrollador a extraer las métricas de forma más asertiva. Además, al hacer que esta información esté disponible en su Portal del desarrollador, todos los que consumen estas llamadas estarán al tanto de estas estandarizaciones y de la representación de retorno.

El uso adecuado de HTTP Status

Sabemos que muchos desarrolladores están bien informados en todos los procesos de uso de la API y que estas normas de código son conocidas en todo el mundo, pero el hecho de que esta información esté disponible junto con la explicación/representación de lo que significará cada devolución dentro de su integración ayudará al desarrollador a comprender más fácil y rápidamente los posibles errores de uso.

Además, esto permite su propia integración disponible para estos fines para seguir estas normas determinadas desde el principio, incluso asegurando una mejor vigilancia y seguimiento de tales errores.

Suponiendo que, en su primera API disponible para el consumo, siguiera estas normas de código, pero que, por alguna razón, otro equipo pusiera a disposición una nueva API sin seguir también estas normas. Esto puede generar una divergencia en el uso por parte del desarrollador y también “interferirá” sus métricas. Utilizando este escenario de estandarización como ejemplo, podemos asumir, por ejemplo, que su desarrollador hace un POST para insertar información, pero que esta información ya ha sido registrada. Dejando sólo un retorno como predeterminado, por ejemplo, a través de HTTP Status 400 y el mensaje de error que expone este escenario no mostrará este caso en las métricas, pero será una visión general de las diversas razones que pueden causar la "bad request".

Por lo tanto, puede recomendar, por ejemplo, HTTP Status 409 (conflict) o 422 (unprocessable entity). De esta manera, el desarrollador sabrá de inmediato que ese determinado recurso ya ha sido registrado y cuando usted, como propietario de la API, vaya a extraer la métrica, podrá distinguir este caso de otros posibles 4XX más fácilmente y de manera más asertiva.

Como hemos visto, hay varios factores muy interesantes a considerar en relación con las buenas prácticas en el uso de la API y también en la alimentación de los Portales de Desarrollo. Siempre que una API vaya más allá de la simple apertura de una integración, es necesario pensar en la experiencia de su consumo, y cuanto más clara y objetiva sea la comunicación, mejor será su API.

Aquí en Sensedia, tenemos equipos especialmente dedicados a esto y que pueden proporcionar varios aportes sobre cómo hacer que sus recursos estén disponibles. Ahora recomendaremos algunos artículos sobre el tema:

Developer Experience (DX) - Aproveche el uso de sus API ¿Por qué es importantepara el negocio tener un portal para desarrolladores?Cuidado de la API: Qué es la monitorización activa y por qué es importante para sus estrategias digitales

¡Gracias por leer!