Un'applicazione Web dovrebbe essere a conoscenza del suo URL, inclusa la sua sottodirectory?

Question

Un'applicazione Web dovrebbe essere a conoscenza del suo URL, inclusa la sua sottodirectory?

#1 da (6 voti)
#2 da (1 voti)

4

Diciamo che ho impostato un proxy inverso per ottenere traffico al link . Serve URL diversi per sottodirectory, non sotto-domini, per una migliore UX Web.

Il suo comportamento predefinito è indirizzare tutte le richieste a un sito WordPress che ho consegnato al team di marketing che useranno definitivamente per creare un po 'di buzz sui social media e generare lead. Nessuna domanda lì. Il comportamento aggiuntivo del proxy inverso è che tutte le richieste a http://gluten-free-snacks.example.com/my-account/* vengono indirizzate a un server separato che esegue una piccola app CRUD. È in esecuzione express.js o no se preferisci.

Devo scrivere questa app per servire le richieste da / (o ./ , in un altro senso) e nascondere il proxy dal fatto che è disponibile pubblicamente a /my-account/ ?

Da / (agnostico sul suo URL e directory), il codice sembra più autosufficiente e facile da refactoring, e abbiamo separato quello che sembra essere un dettaglio di rete. Tuttavia, tutti i suoi collegamenti HTML ad asset statici come /stylesheets/main.css sono ora danneggiati, perché sono effettivamente disponibili a /my-account/stylesheets.main.css . In realtà, tutti i suoi collegamenti devono diventare relativi, il che danneggia la refactability.

Dovrei:

Rendi l'app pubblicata da / e utilizza i percorsi relativi per i link?
host risorse statiche altrove?
Rendi l'app pubblicata da /my-account/ e utilizza i percorsi assoluti per i link?
Fai qualcosa di diverso perché questo è un problema XY ?

Potrebbero essere applicate più risposte.

web-development web-applications url

posta Eric 04.01.2017 - 17:03

fonte

2 risposte

Leggi altre domande sui tag web-development web-applications url

Quale è meglio, un commento dettagliato centrale o diversi più piccoli? Una funzione per produrre una coppia o una funzione per articolo?

score 6 · Answer 1

L'app dovrebbe essere indipendente dall'URL, per il semplice motivo che non è inusuale:

Per spostare un'app: link diventa link ,
Per avere più tipologie per la stessa app a seconda dell'ambiente, come link , link e link per ambienti di sviluppo, di staging e di produzione.

Una pagina web contiene tre tipi di URL:

URL relativi alla pagina effettiva.

Esempio: main.css
URL relativi alla radice, ovvero il nome del dominio.

Esempio: /index.html
URL assoluti.

Esempio: https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js

Un'applicazione ospitata nel link può puntare a un URL relativo come <link href="main.css"> che porterebbe a link , agli URL relativi alla radice, come <a href="/"> che porterebbe a link e ad URL assoluti come <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js"></script>.

Intuttietreicasi,laposizioneeffettivadell'applicazionenonhaimportanza:puòessereospitatacome link , link , link , ecc. Non appena le risorse relative alla pagina rimangono all'interno dell'app e le risorse relative alla radice rimangono nella root, l'app funzionerà.

Il problema, tuttavia, è quando inizi a utilizzare gli URL relativi alla radice nei casi in cui non sono previsti, e questa è esattamente la situazione con le risorse statiche. Esistono due tipi di risorse statiche:

Le risorse statiche comuni possono essere utilizzate da più applicazioni.

In questo caso, è meglio metterli in un CDN e fare riferimento ad essi attraverso un URL assoluto come link . Non importa se si tratta di un CDN pubblico come Amazon CloudFront o qualcosa che la tua azienda ospita e che potrebbe non essere nemmeno tecnicamente un CDN; l'unica cosa che conta è che gli URL siano assoluti, il che ti dà la flessibilità di poterli utilizzare indipendentemente dall'URL effettivo dell'applicazione.
Le risorse orientate all'applicazione sono utilizzate esclusivamente dall'applicazione. Non vengono mai condivisi con altre app Web.

Qui puoi ancora spostarli su un CDN (se è un CDN effettivo, ti darà anche il vantaggio di ottenere prestazioni migliori e un impatto minore sui tuoi server delle app).

Se, tuttavia, decidi di mantenerli insieme all'app (ad esempio perché il tuo framework preferito esegue il minification e il bundling al volo), quindi utilizza gli URL relativi alla pagina effettiva , non il dominio. In questo modo, saprai che funzionerà indipendentemente dal modo in cui accedi alla tua app, sarebbe link , link , link o link .

Per i rari casi in cui la CDN è eccessivamente complessa da utilizzare e le risorse statiche sono condivise tra diverse app, è possibile risolvere il problema con una semplice riscrittura dell'URL. Quando una pagina ospitata su link punta a link , l'URI verrà automaticamente reindirizzato a, ad esempio, link .

Si noti che l'accesso alla stessa risorsa statica attraverso più URI non è di alcuna utilità per il caching sul lato client, pertanto la riscrittura dell'URL deve essere riservata solo ai casi in cui la CDN è effettivamente difficile da utilizzare. Un'altra soluzione è usare i reindirizzamenti. Qui ottieni i vantaggi della memorizzazione nella cache sul lato client, al costo di una richiesta HTTP aggiuntiva.

score 1 · Answer 2

In generale, direi "no, non è necessario essere a conoscenza dell'URL ITS"

Per l'esempio menzionato, vorrei distinguere l'URL per il microservizio, rispetto all'URL per le risorse che potrebbe incorporare. Ad esempio, se collegherà a immagini e stili, suggerirei che il microservice riceve gli URL di base come parametri separati.