Parametri URL in servizi Web RESTful

3

Mi sto interrogando sull'adeguatezza dei parametri URL nella creazione di risorse RESTful.

Per prima cosa, ecco alcuni contesti. Sto lavorando su un'API che aggiornerà da remoto il software su dispositivi embedded collegati a un dispositivo cloud online. Il flusso di lavoro di base è:

  1. Scopri gli aggiornamenti disponibili
  2. Applica gli aggiornamenti desiderati
  3. Monitora l'avanzamento dell'aggiornamento

La risorsa di rilevamento degli aggiornamenti consentirà agli utenti di pubblicare un nuovo rilevamento degli aggiornamenti.

POST /updateDiscovery?apikey=a1b2c3

L'URL precedente attiverà il rilevamento degli aggiornamenti per tutti i dispositivi. È anche utile per limitare quali dispositivi sono destinati agli aggiornamenti. Esistono due identificatori utilizzati per limitare i dispositivi di destinazione:

  1. un ID dispositivo
  2. un ID di gruppo (che può fare riferimento a molti dispositivi)

Questa restrizione può essere comunicata utilizzando i parametri URL o il corpo della richiesta.

Utilizzo dei parametri URL:

POST /updateDiscovery?deviceIds=1,2,3&groupIds=2,3

Uso del corpo della richiesta:

POST /updateDiscovery
Content-Type: application/json
{
    targets: {
         deviceIds: [1, 2, 3],
         groupIds: [3, 4]
     }
}

In ogni caso, verrà creata una nuova risorsa con la seguente rappresentazione:

{ 
   id: 1,
   targets: {
        deviceIds: [1, 2, 3],
        groupIds: [3, 4]
   },
   status: 'pending',
   ...
}

Quale dei metodi sopra indicati segue al meglio il modello di progettazione RESTful e perché?

    
posta jfocht 10.08.2012 - 03:46
fonte

2 risposte

2

Non c'è alcun problema con l'utilizzo dei parametri nelle chiamate API RESTful, tuttavia si desidera che tutte le chiamate siano su risorse. Al momento hai \updateDiscovery che corrisponde a un'azione, non a una risorsa. Un aggiornamento è una risorsa, quindi proverei a progettarlo in termini di ( \updates )

    
risposta data 10.08.2012 - 03:59
fonte
0

Questa entità "updateDiscovery" mi sembra un po 'troppo astratta. Preferirei una chiara separazione tra "dispositivi" e "aggiornamenti". In questo modo potrei chiamare GET su "/ devices / {deviceId} / updates", per ottenere un elenco di tutti gli aggiornamenti che sono stati applicati a un dispositivo. O OTTIENI su "/ updates? DeviceIds = ..." per ottenere un elenco di aggiornamenti che dovrebbero essere applicati ai dispositivi specificati.

    
risposta data 10.08.2012 - 10:42
fonte

Leggi altre domande sui tag