RESTful Api per client mobili

Question

RESTful Api per client mobili

#1 da (1 voti)
#2 da (0 voti)

1

Sono uno sviluppatore mobile e ho sempre un particolare problema con il mio sviluppatore di servizi web / back-end che crede nella progettazione di un'ape riposante.

Problema: come per il design Restful, ogni API dovrebbe essere di natura atomica, ma questo crea molti problemi ai client, in particolare quelli mobili. Dal momento che per eseguire qualsiasi operazione come l'apertura di una determinata pagina, potrei dover effettuare N chiamate per caricare i dati che forniscono un'esperienza utente molto negativa.

Un caso utente valido per spiegare: in un'applicazione di e-commerce, caricare una pagina dei dettagli del prodotto. In questa pagina dobbiamo mostrare i dettagli del prodotto, le informazioni di inventario, la descrizione dell'offerta, i prodotti correlati, il prodotto consigliato ecc. E come per il resto. Ognuno di essi potrebbe essere una singola API e caricare ognuno di essi singolarmente ucciderà l'esperienza utente e effettuerà una chiamata aggregata è contro Restful principal.

Qualcuno può dirmi come hai risolto / risolto questo problema?

rest mobile ios web-services android

posta Code_Life 31.08.2016 - 19:31

fonte

2 risposte

Leggi altre domande sui tag rest mobile ios web-services android

Come testare l'HTML creato dinamicamente quando i test sono in un file separato? Archivio principale guasto su github con richieste pull

score 1 · Answer 1

Qualcosa da ricordare allo sviluppatore di backend: REST non dice nulla circa la dimensione / complessità degli oggetti nel payload, solo riguardo all'atomicità e alla natura senza stato delle transazioni. È completamente consentito avere un percorso della forma /product/{id}/details che restituisce un payload radicato nello stesso oggetto di /product/{id} ma con informazioni aggiuntive eventualmente estratte da più tabelle. È possibile utilizzare il percorso per variazioni semplici da esprimere o variabili stringa di query se si dispone di requisiti complessi per informazioni aggiuntive facoltative. Dal lato PUT, un PUT a /products/{id} potrebbe guardare a ciò che è presente nel payload e aggiornare le tabelle in base a quello o potrebbe solo aggiornare il prodotto di base e richiedere segmenti di percorso aggiuntivi e / o variabili stringa di query corrispondenti al GET corrispondente per aggiornare tabelle aggiuntive. La scelta dipende da ciò che rende le cose più semplici e più semplici / comprensibili per l'applicazione.

Un'API interna come questa esiste per servire a uno scopo. Se utilizzarlo è rendere le cose più difficili invece che più semplici, questo è un segno sicuro che qualcosa non va bene con l'API.

score 0 · Answer 2

Il compito di un'API è fornire ai sistemi esterni l'accesso alle informazioni. REST propone di modellare tali dati in risorse, con suggerimenti su come lavorare con tali modelli. Nelle API ben scritte, le risorse sono create per rendere il lavoro del cliente il più semplice possibile. In una API pubblica, è difficile. In un'API privata, è molto più semplice.

Sembra che tu stia cercando di forzare un'API generica su un singolo cliente interno. Non c'è niente di sbagliato nel consentire un GET /product-details/{id} . Includilo come collegamento fuori dal prodotto (preferibile) o usa lo stesso ID per product e product-details . Quella risorsa può contenere esattamente quali informazioni richiede la pagina dei dettagli del prodotto. Se l'utente decide di aggiornare il prodotto, il client può richiamare GET /products/{id} per i dettagli completi e quindi PUT /products/{id} per eseguire l'aggiornamento.