Utilizzo di molti URI risorse per creare un record e gestire errori

Question

Utilizzo di molti URI risorse per creare un record e gestire errori

Naviga le tue risposte

#1 da (1 voti)
#2 da (1 voti)

1

Ciao ragazzi,

Ho una decisione da prendere per risolvere un problema, sto descrivendo il problema sotto.

Panoramica dell'applicazione

Ho una webApp ASP.NET MVC 4 che utilizza Rest Api per quasi tutte le attività, da Login a CRUD nei record.

Il resto api è stato sviluppato da un team separato disgiunto e la webApp è stata sviluppata da me.

C'èunoscenarioparticolarechemiportaapensarechequalcosanonsiagiustopotrebbeesserel'ApistaavendounproblemaononstosviluppandolaWebAppnelmodogiusto.
HocreatounoschermoperlacreazionedelDipendente,raccogliediverseinformazionirelativeaundipendente,suinvioalserverraccolgoquesteinformazioniserializzandoleinjsoneinviandoleall'URIdellarisorsautilizzandoilmetodoPOST.

Il problema è che per creare un singolo dipendente avrei bisogno di colpire quattro URI di risorse uno per uno, la Persona deve essere creata prima (è il record indipendente) e quindi posso procedere con il person_id per creare Telefono, Email e Indirizzo .
Persona > (Telefono | Email | Indirizzo)

Possibili problemi:
Ora Se la creazione della persona fallisce, mostrerò all'utente che l'operazione è fallita e lui / lei potrebbe riprovare. Se la creazione della persona ha esito positivo, ma una o più precedenti creazioni del record non riesce, in realtà la creazione del dipendente non riesce, è una specie di transazione che deve essere creata per creare un dipendente. Anche una persona inutile non ne vale la pena e quindi l'utente dell'applicazione potrebbe tentare di creare nuovamente il dipendente e questo problema potrebbe ripetersi.

Soluzioni possibili

A) Soluzione alla fine: Crea un servizio Windows in esecuzione con un programma di pianificazione, che verifica un DB se le richieste non riuscite sono presenti e, se trova, esegue la richiesta API per completare le attività.

B)SoluzionealivellodiAPI:CreaunURIEmployeeResourcechesiaingradodiricevereiljsondituttiglioggettiJSONdistintiinununicopassaggioerispondereconrisultato.NaturalmentequestioggettijsonseparatipossonocorrispondereatabelleDBseparateelosviluppatoreAPIligestiràattraversolatransazione.

C)UsaQueueBackgroundWorkItemutilizzareQBWIpereseguirerapidamentediverserichiesteasincroneperlerisorsenonriusciteerestituireconilmessaggiononriuscitoeriuscitoancheregistrareeinviareviaemailall'amministratore,nonènecessariogestireunservizioWindowsseparatoeunDB.

per ulteriori dettagli su QBWI.

Note: Vado per la soluzione B, sembra l'opzione migliore ma a causa del vincolo di tempo potrei aver bisogno di applicare la soluzione (C)

Ragazzi ho bisogno che tu esamini criticamente lo scenario e le sezioni della soluzione e mi fornisca l'analisi e la migliore soluzione possibile.

design api-design architecture rest application-design

posta Owais Qureshi 25.01.2015 - 18:32

fonte

2 risposte

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

Qualche consiglio su quanta memoria del browser usare? Algoritmi grezzi - minimizzare "rotonde parentesi" per ottenere un'espressione valida

score 1 · Answer 1

B suona sicuramente come l'unica scelta sensata.

A significa in base ai dettagli di implementazione dell'API REST. Rende la "transazione" molto fragile, rompe l'incapsulamento e altre cose cattive.

C Non sono del tutto sicuro di quello che stai dicendo che farai con un QBWI (oltre la parte dell'email per l'amministratore), ma non sembra una vera soluzione al problema. Qualcosa di così semplice e fondamentale come la semantica delle transazioni ha sicuramente bisogno di essere gestito dal software, non dagli amministratori umani.

Nel mondo reale, il "team disgiunto" potrebbe non riuscire a fornire una soluzione reale. Ciò avverrebbe quando parli con i dirigenti aziendali e ti spieghi che puoi fare una soluzione alternativa (A o C) a breve termine, ma in realtà hai bisogno che l'altro team ti dia un giorno un'API adeguata. Sono quelli in grado di decidere se è meglio per la società fare la soluzione alternativa o fare qualcos'altro per il momento.

score 1 · Answer 2

c'è un problema nella tua raccolta dei requisiti Prima hai detto " ... (è il record indipendente) e poi posso procedere con person_id per creare Phone, Email e Address "

allora hai detto: Se la creazione della persona ha esito positivo ma una o più precedenti creazioni del record falliscono, in realtà la creazione del dipendente non riesce "

significa che non è indipendente.

lascia che sia indipendente quindi significa che l'utente può aggiungere o aggiornare la sua risorsa di indirizzo, risorse telefoniche ecc. dopo le parole.

una soluzione come te può ridisegnare questo schermo in modo tale da creare l'utente con Risorsa Person e poi ottenere le sue altre informazioni in seguito.

e se è dipendente allora non puoi disgiungere la risorsa in quel modo, in API hai dato informazioni complete per eseguire attività. La creazione dell'utente è un'attività e le sue informazioni complete sono tutte insieme.