Sto considerando alcuni diversi flussi possibili per un api riposante. Per un prodotto minimo redditizio, presumo un browser web come front-end.
Caso d'uso corrente: il compito dell'operatore umano è creare una raccolta ordinata di entità. Ogni entità avrà alcuni valori assegnati dall'utente. Il presupposto è che l'utente creerà le voci in ordine crescente, ma che sarà necessario eseguire un back tracking per correggere gli errori dei dati.
L'inserimento, la rimozione, il riordino e la normalizzazione saranno supportati da diverse interfacce. Per i valori che possono essere previsti con alta affidabilità, la presentazione iniziale delle risorse di data entry dovrebbe presupporre che tali valori siano immutabili, ma fornire collegamenti a risorse che offrano un maggiore controllo all'operatore umano. L'assistenza dinamica dell'operatore (pensa typeahead) non rientra nell'ambito di applicazione di mVP.
La manipolazione manuale degli URL è non supportata . Si prevede che l'host classifichi gli URL generati esternamente come ostili (ma non per mVP, ovviamente).
Domanda n. 1: c'è qualche precedente che descrive le migliori pratiche per costruire una cosa del genere? Sarebbe bello rivedere, ad esempio, un elenco di casi d'uso che non avevo ancora preso in considerazione prima di investire profondamente nel progetto sbagliato.
Dato che userò un browser come front-end, tutte le richieste che invierò utilizzeranno GET o POST.
Poiché le voci e la lista stessa sono entità, a ognuna verrà assegnato un uuid. Questo sarebbe uno dei valori di alta fiducia che mi aspetto di scusare dall'entrare dell'operatore umano.
Per il primo ordine, il prossimo compito dell'operatore sarà sempre l'inserimento di dati in un modulo. Quindi il design dovrebbe portare il designer alla forma successiva più probabile il più semplicemente possibile.
La home page è pubblicata come punto di accesso all'api. Poiché i casi di utilizzo per le letture sono più comuni dei casi di utilizzo per le scritture, l'operatore dovrà seguire una relazione GET per accedere agli stati di immissione dei dati.
La mia implementazione iniziale ha unito le risorse molto strettamente alle entità.
- Segui (GET) un link al modulo che crea l'entità di raccolta
- Dati dei POST degli utenti sull'endpoint
- Il server genera l'id per la nuova raccolta
- Il server crea la raccolta
- Il server reindirizza l'utente a una rappresentazione della raccolta creata
In questa progettazione, la forma stessa persiste nella posizione specificata, il che limita la quantità di dati transitori che posso includere.
Mi è venuto in mente questa sera che non ho bisogno di chiudermi così strettamente. Un ordine leggermente diverso
- Segui (GET) un link al modulo che crea l'entità di raccolta
- Il server genera l'id per la nuova raccolta
- Il server reindirizza a una rappresentazione del modulo con i nuovi ID specificati
- Dati dei POST degli utenti sull'endpoint
- Il server crea la raccolta
- Il server genera ID per il prossimo passaggio anticipato
- Il server reindirizza l'utente a una rappresentazione della raccolta creata, con un modulo che supporta l'attività successiva, con ID pre-generati, pronti per l'uso.
- tartarughe fino in fondo
Dato che i viaggi "extra" che non richiedono l'intervento dell'operatore umano sono accettabili, ci sono motivi per evitare di perseguire il secondo progetto?