HATEOAS: URL assoluti o relativi?

Nella progettazione di un servizio Web RESTful utilizzando HATEOAS, quali sono i pro e i contro di mostrare un collegamento come un URL completo (" http: // server: port / application / customers / 1234 ") rispetto al solo percorso ("/ application / clienti / 1234 ")?

C'è una sottile ambiguità concettuale quando le persone dicono "URI relativo".

Secondo la definizione di RFC3986 , un URI generico contiene:

  URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

  hier-part   = "//" authority path-abempty
              / path-absolute
              / path-rootless
              / path-empty

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

La cosa complicata è che, quando schema e autorità vengono omessi, la parte "percorso" stessa può essere un percorso assoluto (inizia con /) o un percorso relativo "senza radice". Esempi:

1. Un URI assoluto o un URI completo:"http://example.com:8042/over/there?name=ferret"
2. E questo è un uri relativo, con percorso assoluto :/over/there
3. E questo è un uri relativo, con percorso relativo : hereor ./hereor ../hereor ecc.

Quindi, se la domanda era "se un server deve produrre un percorso relativo in una risposta riposante", la risposta è "No" e il motivo dettagliato è disponibile qui . Penso che la maggior parte delle persone (incluso me) contro "URI relativo" sia in realtà contro "percorso relativo".

E in pratica, la maggior parte dei framework MVC lato server può facilmente generare URI relativo con un percorso assoluto come /absolute/path/to/the/controller, e la domanda diventa "se l'implementazione del server deve anteporre a un scheme://hostname:portdavanti al percorso assoluto". Come la domanda dell'OP. Non sono abbastanza sicuro di questo.

Da un lato, penso ancora che il server che restituisce un uri completo sia consigliato. Tuttavia, il server nonhostname:port dovrebbe mai codificare la cosa all'interno del codice sorgente come questo (altrimenti preferirei eseguire il fallback su uri relativo con percorso assoluto). La soluzione è lato server che ottiene sempre quel prefisso dall'intestazione "Host" della richiesta HTTP. Non sono sicuro che funzioni per tutte le situazioni.

D'altra parte, non sembra molto problematico per il client concatenare il http://example.com:8042percorso assoluto e. Dopo tutto, il client conosce già quello schema e il nome di dominio quando invia la richiesta al server, giusto?

Tutto sommato, direi, consiglio di usare l'URI assoluto, possibilmente fallback all'URI relativo con percorso assoluto, non usare mai il percorso relativo .

Dipende da chi scrive il codice client. Se stai scrivendo client e server, non fa molta differenza. O soffrirai il dolore di costruire gli URL sul client o sul server.

Tuttavia, se stai costruendo il server e ti aspetti che altre persone scrivano il codice client, ti ameranno molto di più se fornisci URI completi. Risolvere gli URI relativi può essere un po 'complicato. Innanzitutto come risolverli dipende dal tipo di supporto restituito. Html ha il tag di base, Xml può avere xml: tag di base in ogni elemento nidificato, i feed Atom potrebbero avere una base nel feed e una base diversa nel contenuto. Se non fornisci al tuo cliente informazioni esplicite sull'URI di base, deve ottenere l'URI di base dall'URI della richiesta, o forse dall'intestazione Content-Location! E fai attenzione a quel taglio finale. L'URI di base viene determinato ignorando tutti i caratteri a destra dell'ultima barra. Ciò significa che la barra finale è ora molto significativa quando si risolvono gli URI relativi.

L'unico altro problema che richiede una piccola menzione è la dimensione del documento. Se restituisci un ampio elenco di elementi in cui ogni elemento può avere più collegamenti, l'utilizzo di URL assoluti può aggiungere una quantità significativa di byte alla tua entità se non comprimi l'entità. Questo è un problema di prestazioni e devi decidere se è significativo caso per caso.

L'unica vera differenza sembrerebbe essere che è più facile per i client se consumano URI assoluti invece di doverli costruire dalla versione relativa. Ovviamente quella differenza sarebbe sufficiente per convincermi a fare la versione assoluta.

Man mano che la tua applicazione si ridimensiona, potresti voler eseguire il bilanciamento del carico, il failover, ecc. Se restituisci URI assoluti, le tue app lato client seguiranno la tua configurazione in evoluzione dei server.

Utilizzando la tricotomia di RayLou, la mia organizzazione ha optato per la preferenza (2). Il motivo principale è evitare gli attacchi XSS (Cross-Site Scripting). Il problema è che se un utente malintenzionato può inserire la propria radice URL nella risposta che torna dal server, le successive richieste dell'utente (come una richiesta di autenticazione con nome utente e password) possono essere inoltrate al server dell'attaccante *.

Alcuni hanno sollevato il problema di essere in grado di reindirizzare le richieste ad altri server per il bilanciamento del carico, ma (sebbene questa non sia la mia area di competenza) scommetterei che ci sono modi migliori per abilitare il bilanciamento del carico senza dover reindirizzare esplicitamente i client a diversi host.

* per favore fatemi sapere se ci sono dei difetti in questo ragionamento. L'obiettivo, ovviamente, non è impedire tutti gli attacchi, ma almeno una via di attacco.

Dovresti sempre utilizzare l'URL completo. Agisce come identificatore univoco per la risorsa poiché tutti gli URL devono essere univoci.

Direi anche che dovresti essere coerente. Poiché l'intestazione HTTP Location prevede un URL completo in base alla specifica HTTP, l'URL completo viene restituito nell'intestazione Location al client quando viene creata una nuova risorsa. Sarebbe strano per te fornire un URL completo nell'intestazione Location e quindi gli URI relativi nei collegamenti all'interno del corpo della risposta.

Una considerazione importante nei risultati di API di grandi dimensioni è il sovraccarico di rete aggiuntivo derivante dall'inclusione ripetuta dell'URI completo. Che tu ci creda o no, gzip non risolve completamente questo problema (non so perché). Siamo rimasti scioccati dallo spazio occupato dall'URI completo quando c'erano centinaia di collegamenti inclusi in un risultato.

Uno svantaggio dell'utilizzo di URI assoluti è che l'API non può essere sottoposto a proxy.

Riprendilo ... non è vero. Dovresti cercare un URL completo che includa il dominio.

Per quanto riguarda i pro, vedo la riduzione dei byte da trasmettere a scapito della gestione extra richiesta da un client per il percorso (assoluto). Se desideri disperatamente salvare ogni byte, anche dopo aver provato la codifica del contenuto come gzip, l'uso corretto delle intestazioni di memorizzazione nella cache, l'uso di etags e richieste condizionali sul client, allora questo potrebbe essere necessario alla fine, ma mi aspetto ritorni molto più alti su i tuoi sforzi altrove.

Per quanto riguarda i contro, vedo una perdita di controllo su come puoi dirigere il flusso dei clienti tra le risorse in futuro (bilanciamento del carico, test A / B, ...), e la considererei una cattiva pratica per quanto riguarda la gestione di un web API. L'URL fornito non è più fondamentalmente opaco per il client (vedere Tim Berners-Lee Axioms of Web Architecture on URI opacity ). Alla fine, diventi responsabile di mantenere i clienti soddisfatti del loro utilizzo creativo della tua API, anche se riguarda solo la struttura del tuo spazio URL. Se è necessario consentire una modifica dell'URL definita in modo esplicito, prendere in considerazione l'utilizzo di modelli URI utilizzati nel linguaggio dell'applicazione ipertestuale .