È una cattiva progettazione chiamare internamente endpoint API dall'interno dell'istanza API?

1. È poco utile fare una richiesta HTTP.

   Quando l'applicazione sottostante elabora la richiesta GET dal tuo esempio, probabilmente chiama il livello aziendale che esegue il controllo dell'input, quindi chiama il livello di accesso ai dati che recupera il cucciolo.

   In modo simile, la richiesta POST potrebbe, invece di fare un ulteriore GET, semplicemente chiedere al livello aziendale di aggiornare il cucciolo; il livello aziendale, a sua volta, inizierà chiamando il metodo del livello di accesso ai dati che recupera il cucciolo corrispondente.

2. Tuttavia, fare una richiesta HTTP in più avrà diversi svantaggi.

   • Ci sarebbe un costo per le prestazioni. Ad esempio, disinfetti due volte gli input, mentre farlo una volta è sufficiente. Creare un contesto HTTP ed elaborarlo ha anche un costo; non è enorme, ma perché aggiungerlo quando puoi evitarlo così facilmente?

   • Rende la tua applicazione più complicata che dovrebbe essere. Perché dovresti fare una richiesta HTTP, mentre i dati di cui hai bisogno sono proprio di fronte a te (cioè nell'interfaccia del livello di accesso ai dati)?

     E non sto nemmeno menzionando tutto il codice extra di cui avrai bisogno. Ad esempio, come configurerai l'URI del servizio da chiamare? Verrà messo in configurazione (se sì, cosa succederebbe se il servizio si sposta), o verrà generato al volo (nel qual caso, per quanto tempo ci vorrà per trovare la soluzione giusta, che gestirà le porte, relativo URI, HTTP / HTTPS, ecc.?)

   • Aggiungerà una riga aggiuntiva ai log del tuo server delle app. E i log dei proxy inversi.

   • Renderà il codice più difficile da refactoring. Ad esempio, con la soluzione in cui il livello aziendale chiama il metodo del livello di accesso ai dati che recupera un cucciolo, è del tutto naturale pensare di spostare la logica verso il basso nel livello di accesso ai dati in una forma di query, o forse il database stesso . D'altra parte, quando si fa una richiesta HTTP, si astrae completamente la logica alla base della richiesta GET, rendendo impossibile l'ottimizzazione successiva.

Sì, è cattivo (tm).

Il sovraccarico in più di fare la chiamata http anche se inutilmente probabilmente non sarà molto di un fattore.

Penso che i veri pericoli siano:

• L'introduzione accidentale di loop infiniti. Ad esempio, le chiamate post ricevono e ricevi chiamate post o scenari simili.

• Effetti di cache non indirizzati

• link

• Problemi di threading, quando effettui la chiamata e attendi che venga elaborata in modo asincrono

Fondamentalmente un sacco di bit e bob che non infrangono il tuo codice, ma sicuramente introducono problemi di cui non dovresti preoccuparti.

In ogni caso il tuo codice dovrebbe essere strutturato in modo tale che sia facile effettuare la chiamata get, o parte di essa direttamente. senza colpire il livello http. Sembra che tu non abbia inserito il tuo codice in un livello aziendale

Non so se è cattivo o buono, ma Wordpress lo consente nel suo framework API Rest. Si chiama " richiesta interna " e il suo scopo è quello di facilitare le richieste batch (come in il tuo esempio). Metodo utilizzato per rendere accettabili le richieste interne Oggetto richiesta, non un URL. Basta leggere l'articolo, ti darà un'idea di come potresti codificarlo nella tua soluzione.