Estructuración de la funcionalidad de la API
No tengo mucha experiencia cuando se trata de crear API. He trabajado bastante en lo que respecta a la integración de WordPress con API de terceros, pero he dedicado muy poco tiempo a trabajar en la creación de un sistema que tenga su API con la que otros sistemas puedan interactuar.
En lo que respecta a esto último, en realidad estoy en medio de hacerlo (y estoy aprendiendo mucho). La esencia del proyecto es que hay una aplicación de iOS que interactúa con WordPress a través de la API REST de forma bidireccional.
Estoy ansioso por compartir más al respecto, pero necesito hacerlo cuando el proyecto esté más avanzado.
Pero cuando se trata de trabajar con API de terceros y luego crear componentes de un proyecto de WordPress que interactúen con ellos, dos de las cosas que siempre encuentro útiles son:
- utilizando una biblioteca adecuada ,
- diagramando el sistema,
- separando la funcionalidad en partes.
Y los últimos dos puntos anteriores son los que busco cubrir en esta publicación.
Estructuración de la funcionalidad de la API
No hay código involucrado en esta publicación, pero tal vez sea una guía sobre cómo puede avanzar en su trabajo al estructurar la funcionalidad de la API o hacer algo similar por su cuenta.
Bibliotecas de terceros
Menciono esto solo porque creo que es valioso reutilizar soluciones probadas y verdaderas que han sido probadas (y, por lo tanto, utilizadas) en todos los ámbitos en una variedad de proyectos.
Guzzle es mi biblioteca preferida. Sí, WordPress tiene funciones integradas para comunicarse con otras URL, pero hay más cosas que puede hacer con Guzzle (especialmente en lo que se refiere a los componentes de la solicitud) que con WordPress.
De acuerdo, esta es mi opinión, pero disfruto trabajando con ella. Y la documentación es sólida.
Diagramación del sistema
Cuando trabaje con la integración con API de terceros durante el tiempo suficiente, se acostumbrará al proceso de configuración del funcionamiento del sistema. Por lo general, es algo como esto:
- crear un cliente API para conectarse a la API,
- configurar las funciones necesarias para realizar las solicitudes que necesites,
- analizar la respuesta,
- devolverlo al objeto o función original que invocó la solicitud.
Esto es un poco simplificado (después de todo, crear el cliente API puede ser una tarea en sí misma), pero todos los puntos siguen siendo los mismos (y puede que no sean una mala serie 🤔).
De todos modos, por encima de todo, nunca está de más diagramar el sistema. Esto es algo que todavía hago porque me ayuda, en cierto sentido, a articular lo que estoy construyendo y ver si hay brechas en el flujo de control a través de la aplicación.
He aquí por qué, si no por otra razón, esto es importante: articular lo que va a hacer lo ayuda a comprender lo que está haciendo y, a menudo, expone lagunas en su pensamiento que da por sentado.
Entonces, cuando se trata de diseñar un sistema, no asuma que lo tiene todo resuelto.
Separando la funcionalidad
Si ha leído este blog durante algún tiempo, entonces sabe que soy fanático de seguir todas las ideas de desarrollo de "separación de preocupaciones".
Esto es cierto por múltiples razones, la menor de las cuales no es:
- poder realizar pruebas unitarias de un cliente API de forma aislada,
- manteniendo el código de comunicación con el front-end y el back-end independientes.
Cuando tiene una clase dedicada a ejecutar la lógica empresarial en los valores, puede descargar gran parte del manejo de errores en la clase intermedia.
Esto significa que la clase central responsable de la mayor parte de la lógica comercial debe tener exactamente lo que necesita para hacer su trabajo. Esto no significa que no se deba realizar una verificación de errores (división por cero o algo así, ¿sabes?), Pero significa que los datos se pueden verificar incluso antes de que lleguen a la clase principal a través de la clase intermedia.
Y no solo puede verificar si falta información, sino que también puede informar esos errores al front-end.
Tres puntos para recordar
Si está creando un sistema que depende de Ajax en WordPress, el objetivo de todo esto es triple:
- diagrama el sistema que estás creando,
- crear una clase intersticial para manejar cualquier información faltante y reportar los errores,
- solo envíe la información completa a la clase comercial central después de que se haya verificado toda la información.
Una vez que haya hecho eso, el objetivo sería que la clase empresarial principal devuelva los valores solicitados sin errores, ya que se habrán capturado antes incluso de alcanzarlos.