Oggetto REST con risorse

Question

Oggetto REST con risorse

#1 da (2 voti)

3

Sto progettando un'API REST basata su HTTP. Diciamo che ho un'entità chiamata Entity che ha un sacco di proprietà. Alcune delle sue proprietà sono file. Diciamo che Entity ha le seguenti proprietà:

name: string
description: string
photos: array of photos
videos: array of videos

L'API è progettata per essere utilizzata dai dispositivi mobili e dovrebbe funzionare bene in condizioni di connessione lenta o instabile. Il fatto è che l'oggetto non dovrebbe essere considerato completo fino a quando non carico tutte le risorse del client.

Quale è il modo migliore per costruire un nuovo oggetto?

Per ora ho trovato la seguente soluzione. Aggiungi flag di readiness isReady , inserisci prima i dati dell'oggetto di base all'interno di single json:

POST /entities/ {name: "somename", description: "description", isReady: false}
obtain id of newly created 'entityId'

Quindi carica le risorse una alla volta:

POST /entities/{entityId}/photos/ <photo data>
POST /entities/{entityId}/videos/ <video data>

Quindi aggiorna il flag di preparazione dell'oggetto

PUT /entities/{entityId}/ {isReady: true}

La seconda soluzione che viene in mente è creare endpoint separati per foto, video. Quindi potrò pubblicare prima foto e video e quindi creare Entity con riferimenti alle risorse.

POST /photos <photo data>
obtain ids
POST /videos <video data>
obtain ids

POST /entities/ {name: "somename", description: "description", photos: ids[], videos:ids[]}

La domanda con la seconda soluzione: va bene che la risorsa venga referenziata di più URIs ?

/entities/photos/{photoId}
/photos/{photoId}

La prima soluzione è corretta? Il secondo non sarebbe complicato?

Grazie in anticipo

api-design architecture rest web-api

posta Max Komarychev 20.04.2014 - 22:15

fonte

1 risposta

Leggi altre domande sui tag api-design architecture rest web-api

DDD: come riconciliare un BoundedContext con DTO REST / WebService? Come elaborare la transizione dello stato del documento?

score 2 · Accepted Answer

Ho usato con successo entrambi i pattern; ed entrambi funzioneranno bene. Non direi che sia più complicato dell'altro. Una cosa che potresti anche considerare, per il primo schema, è includere nella descrizione dell'entità una "promessa" da soddisfare. Ad esempio, potresti avere un oggetto JSON che enumera i dati che fornirai:

photos_promise: {
    expect: 5,
    checksums: [..., ..., ..., ..., ...]
}

Quindi, quando carichi le cinque foto, puoi eseguire una convalida aggiuntiva per assicurarti che il file di foto che hai ricevuto corrisponda a uno dei checksum forniti. Quando hai ricevuto cinque foto e tutte corrispondono, puoi fare in modo che il servizio "attivi" automaticamente la tua risorsa Entity. Puoi fare un ulteriore passo avanti e avere "stati parziali" per questi oggetti, in modo tale che quando ottieni questa entità dopo aver pubblicato tre foto, ottieni:

photos: [{url: ..., ...}, ...],
photos_promise: {
    received: 3,
    expect: 2,
    checksums: [..., ...] 
}

Ovviamente fa aggiunge complicazione, ma è anche piuttosto elegante.