buona pratica: API REST come interfaccia tra il livello di interfaccia e il livello aziendale?

Question

Stavo pensando l'architettura di un'applicazione web che sto progettando sulla costruzione e mi sono ritrovato a pensare molto su una parte fondamentale della domanda. Dal momento che voglio creare, ad esempio, un'applicazione Android per accedervi, stavo già pensando di avere un'API.

Dato che desidererei avere un'API esterna alla mia applicazione sin dal primo giorno, è una buona idea usare quell'API come interfaccia tra il livello dell'interfaccia (web) e il livello aziendale della mia applicazione? Ciò significa che anche l'interfaccia principale della mia applicazione accederà ai dati tramite l'API. Quali sono gli aspetti negativi di questo approccio? prestazione?

In termini più generali, se si sta creando un'applicazione Web a cui è probabile che sia necessario l'accesso in diversi modi, è un buon progetto architettonico avere un'API (servizio Web) come interfaccia tra il livello di interfaccia e livello aziendale? REST è un buon "strumento" per questo?

Answer 1

Sembra che tu abbia due domande lì, quindi la mia risposta è divisa in due parti.

In primo luogo, dovresti utilizzare un'API tra il livello di interfaccia e il livello aziendale? Questo è sicuramente un approccio valido, che sto usando nel mio progetto attuale, ma dovrai decidere da solo sui benefici, perché solo tu conosci il tuo progetto. Forse il fattore più importante da considerare è se ci saranno abbastanza diversi clienti che accedono al livello aziendale per giustificare lo sforzo di sviluppo extra nello sviluppo di un'API? Spesso questo significa semplicemente più di 1 client, in quanto i vantaggi di avere un'API saranno evidenti quando si arriva a rilasciare modifiche o correzioni di bug.Considerare anche la complessità aggiuntiva, il sovraccarico di manutenzione del codice extra e tutti i vantaggi che potrebbero derivare dalla separazione dell'interfaccia e dei livelli aziendali, come l'aumento della testabilità.

In secondo luogo, se si implementa un'API, si dovrebbe utilizzare REST? REST è un'architettura, che dice tanto su come viene sviluppata la parte restante della tua applicazione come fa l'API. Non è utile definire le risorse a livello di API che non si traducono in Business Layer. Il riposo tende ad essere un buon approccio quando vuoi che molte persone siano in grado di svilupparsi contro la tua API (come NetFlix per esempio). Nel caso del mio attuale progetto, siamo andati per XML su HTTP, perché non abbiamo bisogno dei benefici che Rest offre generalmente (o SOAP per questo).

In generale, la regola generale è quella di implementare la soluzione più semplice che funziona, e senza codificarsi in un angolo, sviluppare per le esigenze di oggi, non di domani.

Chris

Answer 2

Certo, resto potrebbe essere usato per questo. Ma prima chiediti, ha senso? REST è uno strumento come un altro, e mentre uno buono, non sempre è il miglior martello per ogni unghia. Il vantaggio di costruire questa interfaccia è che, IMO, renderà più facile in futuro creare altri usi per questi dati, forse qualcosa a cui non hai ancora pensato. Se decidi di utilizzare un'API REST, la tua prossima domanda è, quale lingua parlerà? Ho trovato che AtomPub è un ottimo modo per processi/applicazioni per lo scambio di informazioni ed è molto estensibile in modo da poter aggiungere molti metadati personalizzati e tuttavia essere ancora facilmente analizzato con qualsiasi libreria Atom. Microsoft utilizza AtomPub nella sua piattaforma cloud [Azure] per parlare tra i produttori di dati e i consumatori. Solo un pensiero.

Answer 3

La mia recente preferenza, che si basa su J2EE6, è quello di implementare la logica di business nel bean di sessione e quindi aggiungere servizi SOAP e riposante web, se necessario. È molto semplice aggiungere la colla per implementare i servizi Web attorno ai bean di sessione. In questo modo posso fornire il servizio che ha più senso per una particolare applicazione utente.

Answer 4

sarà sicuramente bisogno di bisogno di uno strato di Web Service, se si sta andando ad essere accedervi da un client nativo su Internet.

Ci sono ovviamente molti approcci e soluzioni per raggiungere questo però ritengo che la corretta linea guida architettonica da seguire è quello di avere un ben definito Service Interface sul server a cui si accede dal Gateway sul client. Dovresti quindi utilizzare POCO DTO (Plain old DTO's) per comunicare tra gli endpoint. Lo scopo principale del DTO è quello di fornire una rappresentazione ottimale del vostro servizio web attraverso il cavo, permette anche di evitare di avere a che fare con la serializzazione come dovrebbe essere gestito in modo trasparente dalle librerie client Gateway e Service Interface.

Dipende molto da come grande il tuo progetto/app è se vuoi o non vuoi passare allo sforzo di mappare i tuoi DTO ai modelli di dominio client e server. Per le applicazioni di grandi dimensioni l'approccio generale dovrebbe essere sul client per mappare i DTO ai modelli di interfaccia utente e fare in modo che le viste dell'interfaccia utente siano collegate. Sul server si mappare i DTO ai tuoi modelli di dominio e in funzione della realizzazione del servizio, persistono.

REST è un pattern architetturale che per i piccoli progetti che considero un ulteriore sovraccarico/complessità in quanto non è come buona misura programattic rispetto ai servizi web RPC/Document Centric.In poche parole l'idea generale di REST è di sviluppare i tuoi servizi intorno alle risorse . Queste risorse possono avere rappresentazioni multiple che il tuo servizio web dovrebbe fornire a seconda del tipo di contenuto preferito indicato dal tuo client HTTP (ad esempio, nell'ACCETTAZIONE HTTP ACCEPT). Anche gli URL canonici per i tuoi servizi web dovrebbero essere logicamente formati (ad es./Clienti/rapporti/1 in contrapposizione a/GetCustomerReports? Id = 1) e i tuoi servizi web restituirebbero idealmente l'elenco di "stati validi che il tuo cliente può inserire" con ciascuno risposta. Fondamentalmente, il REST è un buon approccio per promuovere un'architettura liberamente accoppiata e il riutilizzo richiede tuttavia uno sforzo maggiore per "aderire" rispetto ai servizi web standard basati su documenti RPC/i cui vantaggi sono improbabili che siano visibili in piccoli progetti.

Se si sta ancora valutando la tecnologia del servizio Web da utilizzare, è possibile prendere in considerazione l'utilizzo del mio open source web framework in quanto ottimizzato per questa attività. I DTO che usi per definire la tua interfaccia web con i servizi possono essere riutilizzati sul client (che normalmente non è il caso) per fornire un'interfaccia fortemente tipizzata in cui tutte le serializzazioni sono prese per te. Offre inoltre l'ulteriore vantaggio di abilitare automaticamente ogni servizio Web creato da SOAP 1.1/1.2, servizi Web XML e JSON senza alcuna configurazione aggiuntiva in modo da poter scegliere il punto finale più ottimale per ogni scenario client, ad esempio Native Desktop o Web App, ecc.

Answer 5

Abbiamo avuto la fortuna di fare qualcosa del genere su un progetto. I nostri servizi Web eseguono principalmente la gestione dei contenuti standard, con un'alta percentuale di letture (GET) per le scritture (PUT, POST, DELETE). Quindi se il tuo livello logico è simile, questo è un approccio molto ragionevole da considerare.

In un caso, abbiamo un'app per video player su Android (Motorola Droid, Droid 2, Droid X, ...) supportata da una serie di servizi Web REST nel cloud. Questi espongono un catalogo di contenuti video on demand, abilitano la configurazione e la rimozione della sessione video, gestiscono il bookmarking e così via. REST ha funzionato molto bene per questo.

Per noi uno dei principali vantaggi di REST è la scalabilità: poiché le risposte RESTful GET possono essere memorizzate nella cache dell'infrastruttura HTTP, molti altri client possono essere offerti dalla stessa applicazione web.

Ma REST non sembra adattarsi molto bene ad alcuni tipi di business logic. Ad esempio, in un caso ho concluso un'operazione di manutenzione quotidiana dietro un'API di servizi web. Non era ovvio quale verbo usare, dal momento che questa operazione leggeva i dati da una fonte remota, la usava per fare un sacco di creazioni e aggiornamenti a un database locale, quindi cancellava i vecchi dati, poi se ne andava e diceva a un sistema esterno fare cose Così ho deciso di fare di questo un POST, rendendo questa parte dell'API non-RESTful. Tuttavia, disponendo di un livello di servizi Web in aggiunta a questa operazione, è possibile eseguire lo script giornaliero su un timer, eseguirlo in risposta a un evento esterno e/o eseguirlo come parte di un flusso di lavoro di livello superiore.

Poiché si utilizza Android, dare un'occhiata a Java Restlet Framework. C'è un Restlet edition supporting Android. Il direttore dell'ingegneria di Overstock.com mi ha entusiasmato fino a pochi anni fa, e tutto ciò che ci ha detto era vero, è una struttura fenomenale e ben fatta che semplifica le cose.