Architettura multitier tramite API

Question

Architettura multitier tramite API

#1 da (2 voti)

2

Ho letto un numero di post e sono propenso a creare un SOA.

Le mie principali dipendenze sono:

Necessità di supportare più client
È necessario che i singoli ambienti client non influiscano su altri ambienti client

Ad esempio, se voglio aggiungere un campo di testo all'applicazione del cliente A, ma non voglio che il client B venga eseguito in alcun modo.

La soluzione che ho è di inviare un indirizzo API insieme al token di autenticazione del client. Ad esempio, il client invierà qualcosa come questo:

api: http://myWebsite/api/clients/ClientA/someServiceCall

Allo stesso modo, da un token, il controller (MVC) saprà quale vista visualizzare per un determinato utente.

La mia domanda è, questa è una buona soluzione al mio problema?

Comprendo che devo chiamare un servizio REST HTTP per l'accesso ai miei dati; ma, sento che questo risolve un sacco di problemi. Ad esempio, potrei vedere quali servizi inviano 404 errori e li sistemo (presumibilmente) prima che vengano persino segnalati.

Ho letto un numero di articoli che sembrano far valere la mia idea. Ho frainteso questo concetto? C'è un approccio architettonico migliore?

Ecco cosa ho letto:

Ancora una volta, l'obiettivo è di mantenere i singoli ambienti client il più separati possibile; in modo tale che se apportiamo una modifica al livello di servizio, non ci sono tempi di inattività e nessuno viene disconnesso a causa di un aggiornamento del pool di applicazioni.

Il mio piano generale è di incorporare queste chiamate API ovunque siano necessarie; Ad esempio, in un controller MVC o una chiamata AJAX javascript. Ad esempio:

public class HomeController : Controller
{
    public ActionResult Index()
    {
        WebClient client = new WebClient();
        string api = /* api from auth token */
        User result = JsonConvert.DeserializeObject<User>(client.DownloadString(api));
        return View(result);
    }
}

architecture rest asp.net-mvc soa

posta user1477388 30.06.2014 - 23:13

fonte

1 risposta

Leggi altre domande sui tag architecture rest asp.net-mvc soa

Progettazione del database MySQL - Opinioni Come modellare una relazione one-mandatory-of-many

score 2 · Answer 1

The solution I have is to send an API address along with the client auth token. For example, the client will send something like this:

api: http://myWebsite/api/clients/ClientA/someServiceCall

Non penso sia una buona idea. Quello che stai cercando di fare qui è creare API separate per tipi di client separati. Diventerà rapidamente un compito complicato. Dico: crea una buona API, offrila ai clienti nel loro complesso e controlla ciò che ogni cliente può fare con esso tramite token di accesso e permessi per token.

Similarly, from a token, the (MVC) controller will know which view to render for a given user.

Non so come vuoi che questo sia implementato, ma secondo me il servizio web dovrebbe funzionare solo con i dati. Dovrebbe essere separato dalla GUI con tutti i mezzi.

Again, the goal is to keep individual client environments as separate as possible; such that if we push a change to the service layer, there is no downtime and no one gets logged out because of an app pool refresh.

Che cos'è un ambiente client nella progettazione? Sicuramente non è un'API?

Again, the goal is to keep individual client environments as separate as possible; such that if we push a change to the service layer, there is no downtime and no one gets logged out because of an app pool refresh.

Nei client del modello REST non si mantiene una connessione costante al server. Quindi non c'è bisogno di preoccuparsi del riavvio del servizio. Se hai bisogno di alcuni dati per persistere tra le chiamate, implementalo utilizzando alcuni oggetti dati o token.

Should a website use its own public API?

Sono completamente d'accordo con Steve su questa domanda. Se non usi la tua API, significa che l'API non sarà ... utile (perdona il mio gioco di parole qui). Ma utilizzando l'API non significa necessariamente che devi effettivamente effettuare alcune chiamate HTTP all'API del servizio. Significa che il codice, che funziona sulla tua piattaforma dovrebbe essere lo stesso, utilizzato dalla tua API REST. Puoi esporre solo parte delle funzionalità tramite API: va bene.