Ho un problema di progettazione nel mio REST API, dove ho una risorsa Device , che capita di rappresentare un dispositivo IoT, può essere parzialmente aggiornato usando PATCH, ma alcune delle cose che vengono aggiornate inizieranno un lavoro di lunga durata.
Ad esempio,
Ecco il dispositivo di classe:
public class Device
{
public int Id { get; set; }
public string Name { get; set; }
public string Ip { get; set; }
public string Foo {get; set; }
}
Posso fare una richiesta PATCH in questo modo:
PATCH /api/devices/1234
{
name: "abc123",
Foo: "hello"
}
che aggiornerà sia il nome & Proprietà della barra del dispositivo.
Tuttavia, se voglio aggiornare il campo Ip usando l'aggiornamento parziale in questo modo:
PATCH /api/devices/1234
{
name: "abc123",
ip: "1.2.3.4"
}
Il problema è che l'aggiornamento di ip on Device attiva una chiamata API al dispositivo IoT fisico per impostare l'ip, che provoca il riavvio del dispositivo.
Solitamente per lavori di lunga durata, farei qualcosa di simile a ciò che è descritto qui e restituisce 202 accettato con l'URL della risorsa in modo da poter tracciare l'operazione.
È una buona idea farlo in combinazione con un aggiornamento parziale? Supponiamo che il campo ip sia specificato nella mia patch, ha senso fare qualcosa del genere:
PATCH /api/devices/1234
{
name: "abc123",
ip: "1.2.3.4"
}
Response:
{
location: "/api/tasks/123"
}
In questo modo è possibile tenere traccia della richiesta, in modo che il client possa sapere quando il dispositivo è stato riavviato con successo ... Ma è strano che l'API a volte risponda in questo modo. Solo se specifichi una proprietà che attiverà un lavoro di lunga durata ... Non sei sicuro di quale sia la scelta di design migliore qui.
Qualsiasi consiglio è benvenuto.