Progettazione API REST per la clonazione di una risorsa

Question

Sto scrivendo un documento YAML usando swagger per progettare un metodo API RESTful per la clonazione di una risorsa. Ho alcune opzioni e non so quale sarebbe il migliore. Per favore qualcuno può avvisare?

Opzioni:

1. Abbandonare la responsabilità di clonare l'oggetto risorsa per il consumatore (dove il consumatore assegna valori alle proprietà in un nuovo oggetto e quindi crea un nuovo oggetto), il processo avrebbe bisogno di consistono in due richieste all'API: un GET contro una risorsa per l'oggetto di origine e quindi un POST a quella risorsa per crearne uno nuovo. Sembra che il consumatore abbia troppe responsabilità.
2. Utilizzo delle estensioni HTTP WebDAV che fornisce un metodo COPIA (see here). Sembrerebbe che questo è esattamente quello che vorrei per la clonazione. Tuttavia, vorrei attenersi ai metodi standard, per quanto possibile
3. postando/{} risorsa? ResourceIdToClone = {id} dove resourceIdToClone è un parametro opzionale. Ciò sarebbe in conflitto con un percorso API che ho già per la creazione della risorsa, in cui aggiungo uno schema al corpo POST. Significa usare un POST a/{resource}/per creare e clonare, e questo violerebbe SRP.
4. Aggiunta di una nuova risorsa denominata "CloneableResource" ed esecuzione di un POST a/CloneableResource/{resource_type}/{resource_source_id}. Per l'esempio della clonazione di una pecora, devi eseguire un POST a/CloneableResource/Sheep/10. In questo modo, sarebbe possibile attenersi all'utilizzo dei metodi HTTP standard, non ci sarebbero conflitti con altri percorsi di risorse (o violazione SRP). Tuttavia, aggiungerei un nuovo tipo potenzialmente superfluo al dominio. Non riesco nemmeno a pensare a uno scenario in cui un consumatore vorrebbe eseguire qualcosa di diverso da un POST a questa risorsa, quindi lo mi sembra un odore di codice.
5. GET contro/resource/{id}? Method = clone. Uno dei vantaggi qui è che non è richiesta alcuna risorsa aggiuntiva e può essere determinata da un semplice parametro querystring opzionale. Sono consapevole che uno dei rischi qui è che può essere pericoloso fornire funzionalità di post o eliminazione utilizzando un metodo GET se l'URL si trova in una pagina Web in quanto potrebbe essere sottoposto a scansione da un motore di ricerca.

Grazie per qualsiasi aiuto!

Answer 1

Influenzato dai requisiti del progetto e dalla gamma di preferenze tra i membri della mia squadra, l'opzione 1 ci servirà meglio in questa fase.

• Conforme ai metodi HTTP standard sarà semplificare e chiarire il mio API
• Ci sarà un unico approccio, coerente per la clonazione di una risorsa. Questo supera il problema che ho con la designazione del lavoro di clonazione al consumatore.

Answer 2

Se si desidera COPY una risorsa, quindi, sì, la COPIA è una scelta ovvia.

(e sì, sarebbe meglio tirare le definizioni di COPY e MOVE da RFC 4918 per districarle da WebDAV).

Answer 3

La maggior parte di queste opzioni è una scelta perfetta. Molto, solo la tua scelta di stile alla fine. Ecco i miei commenti su ciascuna delle tue opzioni.

1. Abbandonare la responsabilità di clonare l'oggetto risorsa per il consumatore
   In generale io in realtà non ho un problema con questa soluzione. Questa opzione è molto semplice da comprendere e implementare per un utente. Potrebbe essere meglio che inventare alcune funzionalità di clonazione proprietarie che i tuoi utenti devono imparare a usare.

2. Utilizzando le estensioni HTTP WebDAV che fornisce un metodo di copia
   mi piace attaccare ai metodi standard pure. Non userei lo COPY, ma non lo terrei male se lo facessi.

3. postando/{} risorsa? ResourceIdToClone = {id}
   Questa è una buona soluzione perfetta. Da un punto di vista REST, non hai realmente un conflitto con il resto della tua API. L'URI con un parametro di query identifica una risorsa diversa dall'URI senza il parametro di query. I parametri di query sono una funzionalità URI per l'identificazione di risorse a cui non è possibile fare riferimento gerarchicamente. Tuttavia, potrebbe essere difficile separarli nel codice a causa del modo in cui la maggior parte dei framework REST funziona. Potresti fare qualcosa di simile a questo tranne con un URI gerarchico come /{resource}/clone. È possibile eseguire il POST di questo URI e passare lo resource_source_id nel corpo.

4. Aggiunta di una nuova risorsa chiamata 'CloneableResource' e l'esecuzione di un POST/CloneableResource/{resource_type}/{resource_source_id}
   Non c'è niente di sbagliato in questo approccio dal punto di vista REST, ma penso che l'aggiunta di una nuova il tipo non è necessario e fa in modo che l'API sia ingombrante. Tuttavia, non sono d'accordo con la tua intuizione, potrebbe esserci un problema con una risorsa che ha solo un'operazione POST. Succede. Nel mondo reale, non tutto si adatta bene a GET, PUT o DELETE.

5. A GET contro/risorse/{id}? Method = clone
   Questa è l'unica opzione del 5 che non posso perdonare. Dalla tua descrizione sembra che tu capisca già perché questa è una cattiva idea, quindi non sono sicuro del motivo per cui la stai prendendo in considerazione. Tuttavia, tutto ciò che devi fare per rendere questa una buona soluzione è cambiare GET in POST. Diventa quindi molto simile alla soluzione n. 3. L'URI potrebbe anche essere gerarchico invece di utilizzare un parametro di query. POST /resource/{id}/clone funzionerebbe altrettanto bene.

Spero sia stato utile. Buona fortuna con la vostra decisione.