Nomi di dominio vs percorso URL per servizi Web

Is there a reason to prefer either dev.taxService.api.company.com or dev.company.com/api/taxService?

Sembra fondamentalmente che la tua domanda si riduce a se è meglio usare sottodomini o sottodirectory per separare i servizi.

Sembra che ci sia un sacco di persone su entrambi i lati del recinto, ad esempio:

Google sembra preferire le sottodirectory, ecco due esempi di servizi diversi:

• Servizio Gmail: link
• Servizio di analisi: link

Amazon sembra preferire sottodomini, ad esempio:

• SQS: link
• S3: link

Personalmente generalmente preferisco sottodomini perché:

• Non richiedono un bilanciamento del carico / proxy inverso per mappare la sottodirectory a un servizio.
• Le sottodirectory hanno senso nel contesto di HTTP, ma se il tuo servizio coinvolge altri protocolli allora non può.
• Di solito è più semplice suddividere i servizi tra i fornitori dell'infrastruttura utilizzando sottodomini che è utile durante una migrazione. vale a dire. è possibile spostare facilmente il servizio 1 al provider B puntando il sottodominio lì, mentre il servizio 2 rimane sul provider A. Facendo ciò con una sottodirectory probabilmente si richiederà l'inversione del proxy a un centro dati totalmente separato.

Questa è una domanda interessante e importante, sono sorpreso che non abbia ottenuto molta attenzione.

Oltre alla risposta di @ thexacre, devi considerare il comportamento del tuo cliente e come può scegliere di riutilizzare le connessioni. Dal punto di vista del cliente, un host è una singola entità che può servire richieste a vari percorsi all'interno di una connessione HTTP (la funzione Keep-alive ). Il timeout keep-alive può essere ad es. un minuto ma può essere configurato sul lato client e negoziato con il server. Il secondo fattore è il numero massimo di connessioni simultanee del client, anch'esse configurabili ma in genere limitate al salvataggio delle risorse.

Detto questo, è necessario verificare la frequenza con cui ciascun endpoint verrà chiamato dal client e se il client trarrà vantaggio dal riutilizzo della connessione HTTP. La strategia di un host + più percorsi sembra essere più conveniente dal punto di vista del cliente, perché può scegliere di attivare più richieste contemporaneamente o serializzarle a seconda che voglia salvare le risorse locali (memoria e CPU) o recuperare i dati come Il più velocemente possibile.

D'altra parte, se un client ha a che fare con molti nomi host significa che creerà connessioni HTTP separate con ognuno di essi; il riutilizzo della connessione sarà impossibile.

Poi c'è il lato server. Se si sta eseguendo un'architettura di microservizi significa che per una strategia one-host è necessario disporre di un router di richiesta, un potenziale collo di bottiglia. Dal punto di vista del server, è più conveniente avere nomi host separati per gruppi di endpoint logicamente isolati: si avrà la flessibilità di scegliere un'architettura (microservizio vs. monolitico), cambiando l'architettura in un secondo momento, migrazione come menzionato nell'altra risposta, potenzialmente no bisogno di un router, ecc.

Tutto sommato, direi se il cliente può potenzialmente fare un gran numero di richieste entro un periodo di tempo limitato, e se è importante gestirle in modo efficiente dal lato client, allora il cliente trarrà vantaggio da un minor numero di nomi host , idealmente solo uno. Tuttavia, se il cliente effettua solo poche richieste per volta, considera ciò che è meglio per il tuo servizio e più probabilmente saranno più nomi host.