Installazione client server API

Question

Installazione client server API

#1 da (1 voti)

4

Supponiamo di avere una configurazione in cui è presente un server API e tutte le interazioni ruotano attorno all'API. C'è l'amministratore, i componenti pubblici e di terze parti che interagiscono con il server API.

Supponiamo di avere un modello di e-commerce, i componenti 'hanno le seguenti capacità: Amministrazione - possibilità di gestire prodotti, ordini e informazioni sui clienti Pubblico - possibilità di gestire le informazioni sui clienti e sugli ordini appartenenti all'utente Terza parte - possibilità di recuperare elenco di prodotti, visualizzare gli ordini - creare ordini per conto dell'utente (il significato deve avere l'autorizzazione dell'utente) - visualizzare le informazioni del cliente (è necessaria l'autorizzazione dell'utente)

La mia preoccupazione riguarda l'autorizzazione. Ho familiarità su come gestire la terza parte attraverso il flusso di lavoro OAuth. Ma sono confuso con i componenti Admin e Public. I suddetti due componenti non sembrano adattarsi al flusso di lavoro di OAuth in quanto vi sono in genere 3 attori: server, utente e consumatore.

Ad esempio per il componente pubblico, è l'applicazione frontale in cui gli utenti possono gestire i loro profili, ordinare e visualizzare i prodotti. Tratteremo questo componente come speciale dal punto di vista dell'autorizzazione dell'API. Lo stesso vale per il componente admin che offre la possibilità di gestire quasi tutti gli aspetti della tua applicazione, anche impostando le chiavi API.

Proprio come Facebook, Twitter, ecc. Offrono un'API. Ma internamente comunicano anche usando una sorta di API?

In primo luogo, questi componenti principali (UI per admin e public) NON dovrebbero essere disaccoppiati dal server API?

api

posta chronorep 23.07.2014 - 12:47

fonte

1 risposta

Leggi altre domande sui tag api

Gestire dipendenze opzionali di classe Quando riutilizzo o creo un nuovo Builder

score 1 · Answer 1

Il framework di autorizzazione OAuth 2.0 consente a un'applicazione di terze parti di ottenere un accesso limitato a un servizio HTTP, per conto di un proprietario di risorse, orchestrando un'interazione di approvazione tra il proprietario della risorsa e il servizio HTTP o consentendo la terza domanda di partito per ottenere l'accesso per proprio conto. Questa specifica sostituisce e obsoleta il protocollo OAuth 1.0 descritto in RFC 5849.

Questo è l'abstract di RFC 6749.

Quindi la risposta semplice è per quello che è. La risposta meno faziosa è smettere di pensare in termini di interazioni multiple tutte in una volta. Nonostante tutta la facciata dell'oggetto tutto il codice è sequenziale.

Tratta questa come una cascata di interazioni; dove la tua biblioteca funge da intermediario tra 2 lati. È più difficile essere più specifici senza i dettagli della tua app.

Quello che vorrei fare è la vecchia filosofia unix: creare un programma di test che accetta una chiamata di oggetto da una terza parte, la memorizza in qualche modo e la passa a un thread / oggetto secondario ecc. E poi quella cosa interagisce con il servizio HTTP. Quindi rivisita il design

Perché i vecchi timer raccomandano in questo modo è possibile che non faccia molto, ma illumina la tua comprensione del problema molto più in profondità dei casi d'uso. Inoltre, ora puoi dire al tuo capo che sei al 50% completo con circa il 70% di andare.