Como estruturar a funcionalidade da API
Eu não tenho muita experiência quando se trata de criar APIs. Eu fiz uma boa parte do trabalho quando se trata de integrar o WordPress com APIs de terceiros, mas gastei muito pouco tempo trabalhando na criação de um sistema que tenha sua API com a qual outros sistemas possam interagir.
No que diz respeito a este último, estou realmente no meio de fazer isso (e estou aprendendo muito). A essência do projeto é que há um aplicativo iOS que está interagindo com o WordPress por meio da API REST de maneira bidirecional.
Estou ansioso para compartilhar mais sobre isso, mas preciso fazê-lo quando o projeto estiver mais avançado.
Mas quando se trata de trabalhar com APIs de terceiros e, em seguida, construir componentes de um projeto WordPress que interagem com eles, duas das coisas que considero úteis são:
- usando uma biblioteca adequada ,
- diagramação do sistema,
- separando a funcionalidade em partes.
E os dois últimos pontos acima são o que estou procurando abordar neste post.
Como estruturar a funcionalidade da API
Nenhum código está envolvido nesta postagem, mas talvez seja um guia sobre como você pode avançar em seu trabalho com a estruturação da funcionalidade da API ou fazendo algo semelhante por conta própria.
Bibliotecas de terceiros
Menciono isso apenas porque acho valioso reutilizar soluções testadas e comprovadas que foram testadas (e, portanto, usadas) em vários projetos.
Guzzle é minha biblioteca de escolha. Sim, o WordPress possui funções integradas para comunicação com outras URLs, mas você pode fazer mais com o Guzzle (especialmente no que se refere aos componentes da solicitação) do que com o WordPress.
Concedido, esta é a minha opinião, mas eu gosto de trabalhar com ela. E a documentação é sólida.
Diagramando o sistema
Quando você trabalha com integração com APIs de terceiros por tempo suficiente, você deve se acostumar com o processo de configuração de como o sistema funciona. Normalmente, é mais ou menos assim:
- crie um cliente de API para se conectar à API,
- configurar as funções necessárias para fazer os pedidos que você precisa,
- analise a resposta,
- devolva-o ao objeto ou função original que invocou a solicitação.
Isso é um pouco simplificado (afinal, criar o cliente da API pode ser uma tarefa por si só), mas os pontos permanecem os mesmos (e podem não ser uma série ruim 🤔).
De qualquer forma, acima de tudo, nunca é demais diagramar o sistema. Isso é algo que ainda faço porque me ajuda, de certa forma, a articular o que estou construindo e ver se há lacunas no fluxo de controle através do aplicativo.
Eis por que, se não houver outro motivo, isso é importante: Articular o que você vai fazer o ajuda a entender o que está fazendo e muitas vezes expõe lacunas em seu pensamento que você considera certas.
Portanto, quando se trata de projetar um sistema, não assuma que você já entendeu tudo.
Separando a funcionalidade
Se você lê este blog há algum tempo, sabe que sou fã de seguir todas as ideias de desenvolvimento de “separação de interesses".
Isso é verdade por vários motivos, dos quais menos não são:
- ser capaz de testar a unidade de um cliente de API isoladamente,
- mantendo o código para comunicação com o front-end e o back-end independente.
Quando você tem uma classe dedicada à execução da lógica de negócios nos valores, pode descarregar grande parte do tratamento de erros na classe intermediária.
Isso significa que a classe principal responsável pela maior parte da lógica de negócios deve ter exatamente o que precisa para fazer seu trabalho. Isso não significa que não deve haver alguma verificação de erros (divisão por zero ou algo assim, sabe?), mas significa que os dados podem ser verificados antes mesmo de chegarem à classe principal por meio da classe intermediária.
E não apenas pode verificar qualquer informação ausente, mas também pode relatar esses erros de volta ao front-end.
Três pontos a serem lembrados
Se você está criando um sistema baseado em Ajax no WordPress, o objetivo de tudo isso é triplo:
- diagramar o sistema que você está criando,
- criar uma classe intersticial para lidar com informações ausentes e relatar os erros de volta,
- só envie as informações completas para a classe de negócios principal depois que todas as informações forem verificadas.
Feito isso, o objetivo seria fazer com que a classe de negócios principal retornasse os valores solicitados sem erros, pois eles seriam capturados antes mesmo de alcançá-los.