Il protocollo HTTP ha il supporto integrato per il concetto di operazioni in background o in batch sotto forma di stato codice 202:
10.2.3 202 Accepted
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
I clienti apprezzeranno se la tua risposta 202 include anche un'intestazione Location in cui possono controllare lo stato. Questo è particolarmente importante per qualsiasi test automatico end-to-end.
Non sono sicuro che questa sia davvero la tua domanda, perché una grande parte di essa sembra in realtà riferirsi a Negoziazione di contenuti , che è come archiviare o recuperare "diverse rappresentazioni" di qualcosa. Naturalmente puoi avere solo URL diversi, come /widgets/1/info e widgets/1/blob , ma il modo preferito di farlo è attraverso conneg. Ci sono due intestazioni che sono rilevanti qui:
-
Accept , che specifica cosa il client desidera ricevere ;
-
Content-Type , che specifica cosa il invio in realtà è
Quindi, ad esempio, supponiamo tu abbia un'API widgets che dovrebbe supportare i widget nel formato "ACME" o "OMNI". Il client può inviare in entrambi i formati tramite l'intestazione Content-Type :
Il server deve comprendere entrambe le richieste e scegliere il metodo di analisi corretto basato sull'intestazione Content-Type . Sul lato ricevente, il client specifica con Accept :
Entrambe le richieste sono per la stessa risorsa e usano lo stesso metodo (GET), ma quando il server vede il primo, dovrebbe fornire i dati usando lo schema ACME e quando vedrà il secondo, dovrebbe fornire gli stessi dati nello schema OMNI.
Un notevole vantaggio di questo approccio è che ogni risorsa ha ancora un URI canonico che puoi usare in Location di intestazioni e così via. Non è obbligatorio, ma generalmente è ideale in REST perché ogni risorsa "viva" esattamente a un URI e non più.
Se la differenza è veramente tra data e metadata allora probabilmente dovresti avere una vera risorsa di metadati, come /widgets/123/info , ma se hai a che fare con diverse rappresentazioni di gli stessi dati allora dovresti usare Accept e Content-Type .
I pensa che copre tutti gli aspetti della tua domanda, ma se pensi che manchi qualcosa - per favore chiarisci.