API Web riposante VS Regolatori regolari

2

Sto facendo un po 'di R & D su quello che sembra un argomento molto confuso, ho letto anche alcune altre domande su SO, ma sento che la mia domanda potrebbe essere abbastanza singolare da giustificarmi. Non abbiamo mai sviluppato un'app utilizzando la pura WebAPI.

Stiamo provando a scrivere un'app in stile SPA, in cui il back-end è completamente disaccoppiato dal codice di front-end

Supponendo che il nostro servizio non sappia nulla su chi lo stia accedendo / consumando:

WebAPI sembra la via logica per servire i dati, invece di usare i controller MVC standard e servire i nostri dati tramite un risultato di azione e convertendolo in JSON. Questo per me sembra almeno un design MC ... che sembra strano, e non per quello che MVC era destinato. (guarda mamma ... senza vista)

Quale sarebbe la normale convenzione in termini di azioni di esecuzione (y) chiamate?

La mia sensazione è che la mia comprensione di WebAPI non sia corretta.

Il modo in cui percepisco WebAPI è che deve essere usato in un senso CRUD, ma cosa succede se voglio fare qualcosa del tipo: "InitialiseMonthEndPayment" .... Dovrei creare un controller WebAPI, chiamato InitialiseMonthEndPaymentController, e poi eseguire un POST ... Sembra un po 'strano, al contrario di un controller MVC in cui posso semplicemente aggiungere una nuova azione sul controller MonthEnd chiamato InitialisePayment.

O questo richiede uno spostamento mentale in termini di design?

Ogni ulteriore collegamento su questo argomento sarà davvero utile, poiché temo che implementeremo qualcosa che potrebbe essere strano e che potrebbe trasformarsi in un problema di codifica / manutenzione in seguito?

    
posta Rohan Büchner 30.10.2013 - 14:15
fonte

1 risposta

2

The way I perceive WebAPI, is that its meant to be used in a CRUD sense

sbagliata.

Non conosco lo stile "WebAPI", ma qualsiasi servizio web è molto più di CRUD.

La maggior parte dei servizi "classici" (SOAP, XMLRPC, ecc.) sono un'implementazione dello stile RPC (chiamata a procedura remota), in effetti si effettuano chiamate di funzione dal client a un server. Ciò che ogni chiamata fa dipende da te, ma è meglio se ti assicuri che ogni chiamata lasci il sistema in uno stato completo e coerente. È meglio includere più dati in una singola chiamata e non richiedere due chiamate per rendere concettualmente una singola operazione.

Una proposta diversa è lo stile REST, che pone l'accento sulle cose che vengono gestite e non sulle procedure. Ecco perché tante librerie semplicistiche rendono un CRUD accessibile a distanza e lo chiamano un giorno.

Ma una vera API RESTfull non è CRUD, perché una "risorsa" non è un record del database. Le risorse sono le entità concettuali del tuo sistema, le "rappresentazioni" (in genere i dati JSON) incarnano lo stato di quelle entità. I verbi PUT, POST e DELETE modificano tale stato, magari tramite alcune sottodisoci risorse. (aggiungendo un commento a un thread del forum, eliminando un utente dall'elenco di chi può accedere a qualcosa, ecc.). Il principio di HATEOAS ti consente di "sfogliare" lo stato del sistema e le relazioni e gli elenchi ti offrono più endpoint URL per gestire tutto ciò.

Nel tuo esempio, aggiungere un "pagamento di fine mese" a un elenco di pagamenti (o forse l'elenco di pagamenti di un beneficiario specifico?) è semplicemente un POST con i dati di pagamento all'URL che rappresenta il pagamento "contenitore" . Il server dovrebbe fare tutta la creazione, l'inizializzazione e le relazioni necessarie per assicurarsi che alla fine il sistema si trovi in un nuovo stato completo, senza 'in reciproci'.

    
risposta data 30.10.2013 - 14:58
fonte

Leggi altre domande sui tag