Est-ce une mauvaise conception d'appeler en interne des points de terminaison d'API à partir de l'instance d'API?
Pour le contexte, j'exécute une API REST construite avec Node.js. En raison des rappels et de certains appels DB complexes, j'ai une chaîne de fonctions qui sont asynchrones mais également uniques, il est donc difficile de réduire la redondance. J'ai eu l'idée d'appeler mes propres points de terminaison (différents points de terminaison) à partir du code lui-même afin de pouvoir réduire la redondance. Est-ce une mauvaise pratique?
Par exemple, j'aurais:
app.get("/puppies/:id"...) // Simple get by ID endpoint
app.post("/puppies"...) // Simple puppy update, but checks an attribute of puppy first by getting by ID
Dans le point de terminaison post, il serait bien d'appeler simplement le point de terminaison "get" dans le code postal, mais il semble sale. Pensées?
Il est peu utile de faire une requête HTTP.
Lorsque l'application sous-jacente traite la demande GET de votre exemple, elle appelle probablement la couche métier qui vérifie les entrées, puis appelle la couche d'accès aux données qui récupère le chiot.
De la même manière, la demande POST pourrait, au lieu de faire un GET supplémentaire, simplement demander à la couche métier de mettre à jour le chiot; la couche métier, à son tour, commencera par appeler l'accès aux données méthode de couche qui récupère le chiot correspondant.
Faire une requête HTTP supplémentaire aura cependant plusieurs inconvénients.
Il y aurait un coût de performance. Par exemple, vous désinfecterez les entrées deux fois, tout en le faisant une fois suffit. La création du contexte HTTP et son traitement ont également un coût; ce n'est pas énorme, mais pourquoi l'ajouter quand on peut l'éviter si facilement?
Cela rend votre application plus compliquée qu'elle ne devrait l'être. Pourquoi feriez-vous une demande HTTP, alors que les données dont vous avez besoin sont juste devant vous (c'est-à-dire dans l'interface de la couche d'accès aux données)?
Et je ne mentionne même pas tout le code supplémentaire dont vous aurez besoin. Par exemple, comment allez-vous configurer l'URI du service à appeler? Sera-t-il mis en configuration (si oui, que se passerait-il si le service se déplace), ou sera-t-il généré à la volée (dans ce cas, combien de temps il vous faudra pour trouver la bonne solution, qui gérera les ports, par rapport URI, HTTP/HTTPS, etc.?)
Il ajoutera une ligne supplémentaire aux journaux de votre serveur d'applications. Et les journaux des procurations inverses.
Cela rendra le code plus difficile à refactoriser. Par exemple, avec la solution où la couche métier appelle la méthode de la couche d'accès aux données qui récupère un chiot, il est tout à fait naturel de penser à déplacer la logique vers le bas de la couche - dans la couche d'accès aux données sous la forme d'une requête, ou peut-être la base de données elle-même . D'un autre côté, lorsque vous effectuez une requête HTTP, cela résume complètement la logique derrière la requête GET, ce qui rend impossible l'optimisation ultérieure.
Oui c'est mauvais (tm).
Le surcoût supplémentaire lié à l'appel http, bien qu'inutile, ne sera probablement pas un facteur important.
Je pense que les vrais dangers sont:
L'introduction accidentelle de boucles sans fin. c.-à-d. que les appels postaux reçoivent et reçoivent les appels postaux ou des scénarios similaires.
Effets de mise en cache non indentés
problèmes de serveur http, demandes maximales sur le serveur, etc.
Problèmes de thread, lorsque vous passez l'appel et attendez qu'il soit traité de manière asynchrone
Fondamentalement, beaucoup de bits et de bobs qui ne cassent pas votre code, mais introduisent définitivement des problèmes dont vous ne devriez pas vous soucier.
Dans tous les cas, votre code doit être structuré de manière à ce qu'il soit facile de faire l'appel get, ou une partie de celui-ci directement. sans toucher la couche http. Il semble que vous n'ayez pas mis votre code dans une couche métier
Je ne sais pas si c'est mauvais ou bon mais, Wordpress le permet dans son framework API Rest. Il s'appelle " requête interne " et son but est de facilité de faire des requêtes batch (comme dans votre exemple). La méthode utilisée pour faire des requêtes internes accepte l'objet Request, pas une URL. Il suffit de lire l'article, il vous donnera une idée de la façon dont vous pouvez le coder dans votre solution.