Ok, hai una risorsa in /my/cat .
Supponiamo che un gatto abbia un nome e un colore.
Quando richiedi:
GET /my/cat HTTP/1.1
Accepts: application/json
Hai:
{
name: "Fluffy",
color: "black"
}
Quando richiedi:
GET /my/cat HTTP/1.1
Accepts: image/png
Si ottiene un'immagine simpatica e animata di un gatto nero, magari con un'etichetta "Fluffy" da qualche parte. Questa è una rappresentazione dell'immagine di cat.
Quando richiedi:
GET /my/cat/photo HTTP/1.1
Accepts: image/png
Ottieni la foto reale di questo particolare gatto come immagine PNG. Si noti che questa è una richiesta per un percorso diverso, una richiesta per una sotto-risorsa - la foto del gatto non è un'altra rappresentazione di una risorsa cat (che ha nome + colore).
Quando richiedi:
GET /my/cat/photo HTTP/1.1
Accepts: image/jpeg
Ottieni foto JPEG di questo gatto.
Ora, le specifiche HTTP dicono che un percorso diverso significa una risorsa diversa e che include estensioni di file (non hanno alcun significato speciale in HTTP). Aggiungendo .jpg a un percorso di risorsa stai creando un percorso diverso, che punta a una risorsa diversa.
Per spiegare meglio perché questo è importante guarda la seguente richiesta:
GET /my/cat/photo.jpg HTTP/1.1
Accepts: image/png
Si noti che abbiamo specificato .jpg nel percorso, ma accettiamo solo image/png . Questo non ha molto senso. Cosa dovrebbe fare il server in questo caso? I server ben funzionanti non trattano le estensioni dei file nei percorsi di richiesta in alcun modo speciale e restituiscono un file PNG per tale richiesta. Quindi otteniamo l'immagine PNG di /my/cat/photo.jpg risorsa, non /my/cat/photo risorsa.
Che ne dici di specificare la risoluzione / densità di pixel / qualità dell'immagine richiesta?
Se i creatori di browser avevano le loro priorità, questo è ciò che accadrebbe sul dispositivo DPI (retina):
GET /my/cat/photo HTTP/1.1
Accepts: image/jpeg; ppi=255;
E su smartphone di fascia bassa:
GET /my/cat/photo HTTP/1.1
Accepts: image/jpeg; ppi=100;
Utilizzeresti <img src="/my/cat/photo"> nella tua pagina e il browser aggiungerebbe questi bit extra quando richiedi la risorsa. Il server potrebbe quindi restituire l'immagine appropriata in base al valore ppi . Questo è solo un esempio teorico, vorrei che i browser lo facciano.
Dato che non abbiamo la funzionalità sopra descritta nei nostri browser web, dobbiamo essere espliciti sulla qualità dell'immagine quando effettui una richiesta.
Quindi, che dire di avere /cat/photo-small.jpg , /cat/photo-big.jpg etc?
Se vuoi eseguire correttamente REST / HTTP, dovresti utilizzare lo stesso URL per tutte le "varianti" della tua immagine. I due percorsi precedenti sono due risorse diverse nella semantica REST / HTTP.
Ok, per quanto riguarda il parametro di query, /cat/photo?size=small e /cat/photo?size=big ?
In base alle specifiche HTTP, l'intero URL identifica una risorsa e include protocollo, dominio, percorso e stringa di query. Quindi i due percorsi precedenti sono anche due risorse diverse nella semantica REST / HTTP. Sfortunatamente, le stringhe di query non sono realmente compatibili con la corretta negoziazione dei media (tipo, lingua, qualsiasi altra variante) negoziazione .
E non è possibile impostare alcuna intestazione HTTP (come X-Image-Resolution ) quando si dichiarano i tag <img> nel codice HTML o quando si digita l'URL dell'immagine nella barra degli indirizzi del browser.
Non penso che ci sia davvero un modo "normale" o "standard" per raggiungere il tuo obiettivo al momento. Vedo spesso persone che utilizzano percorsi di immagine diversi o interrogano le stringhe per specificare le varianti dell'immagine, il che funziona in pratica.
E va bene, ma poi dovremmo tutti smettere di fingere di fare il corretto HTTP;)