Breeze e riposante WebAPI

Question

Domanda:

Quale valore brezza fornisce quando ho bisogno di implementare il mio POST/PUT/GET endpoint per entità WebAPI?

Priorità:

This sembra essere un'implementazione comune di un controllore serverside Breeze:

[BreezeController] 
public class TodosController : ApiController { 

    readonly EFContextProvider<TodosContext> _contextProvider = 
     new EFContextProvider<TodosContext>(); 

    // ~/breeze/todos/Metadata 
    [HttpGet] 
    public string Metadata() { 
     return _contextProvider.Metadata(); 
    } 

    // ~/breeze/todos/Todos 
    // ~/breeze/todos/Todos?$filter=IsArchived eq false&$orderby=CreatedAt 
    [HttpGet] 
    public IQueryable<TodoItem> Todos() { 
     return _contextProvider.Context.Todos; 
    } 

    // ~/breeze/todos/SaveChanges 
    [HttpPost] 
    public SaveResult SaveChanges(JObject saveBundle) { 
     return _contextProvider.SaveChanges(saveBundle); 
    } 

    // other miscellaneous actions of no interest to us here 
} 

Sono nel mezzo della costruzione di un'API RESTish che, fino a questo punto, ha endpoint come:

GET /api/todo/1 
PUT /api/todo 
POST /api/todo 

sembra Breeze richiede i punti finali di essere molto simpl er (nel bene o nel male): solo un mucchio di GETS e un endpoint POST di SaveChanges.

Questo mi porta a pensare che Breeze si sviluppi rapidamente con un singolo client Web, beh, un gioco da ragazzi ... ma non appena hai clienti anonimi, devi forzarli in qualsiasi convenzione di brezza che hai creato nel tuo client, che sembra per vanificare lo scopo della progettazione dell'API RESTful. È questo il caso?

Answer 1

Breeze è, in primo luogo e formost, un framework JavaScript sul lato client. Se non si utilizza Breeze sul client, i benefici di Breeze.WebApi sono limitati a

• supporto di query OData avanzato ($ selezionare e $ estendere il supporto, esteso $ orderby)
• salvare i punti di intercettazione (beforeSaveEntity e gli eventi beforeSaveEntities)
• Salva la manipolazione (chiavi di entità aggiornati, colonne di concorrenza) risultato
• metadati estrazione e la serializzazione

Come si è ipotizzato, Breeze ha un diverso phi losophy da REST per quanto riguarda le operazioni CRUD.

Breeze è progettato per i clienti che desiderano C/U/D molte risorse, di tipi diversi, in un'unica transazione. Ciò consente agli utenti di manipolare i dati in modi complessi senza colpire il server, quindi salvare le loro modifiche quando sono pronti. Ad esempio, è possibile creare un nuovo Order, spostare due OrderLineItem da uno Order a un altro, eliminare un terzo OrderLineItem, modificare la quantità su un quarto e quindi SaveChanges(). Breeze supporta anche l'uso di localStorage per funzionare completamente disconnesso dal server. Una volta ricollegato, è possibile salvare tutte le modifiche.

REST è stato progettato per funzionare su one resource at a time. Ogni operazione C/U/D deve essere eseguita sul server immediatamente in modo che il codice di risposta possa essere utilizzato. Funziona bene per applicazioni con esigenze di aggiornamento semplici, ma non per applicazioni di immissione dati. Mentre transactions can be supported in REST, sono al massimo ingombranti.

Detto questo, l'API di Breeze sul lato server non è limitata a ciò che vedi nell'esempio di Todos. Breeze supporta Named Saves, che consente di avere endpoint diversi per diverse operazioni. È anche possibile utilizzare Save Interception per assicurarsi che il pacchetto di salvataggio contenga solo i tipi che dovrebbe.E naturalmente, non c'è nulla che ti impedisce di esporre entrambe le API sul tuo server, e di avere entrambi alimentato dallo stesso livello di persistenza.

Se devi decidere tra di loro, dovresti iniziare con i tuoi utenti. Gli utenti reali (non gli sviluppatori) non si preoccupano di REST, si preoccupano di ciò che l'applicazione può fare. In definitiva, REST fornisce alla tua applicazione tutta la semantica di HTTP, e Breeze fornisce tutta la semantica di un database relazionale o di oggetti. Quale da esporre ai tuoi utenti dovrebbe dipendere dai casi d'uso che devi supportare.