Progettazione di un'API in cima con Java RMI e Rest APIs

Question

Progettazione di un'API in cima con Java RMI e Rest APIs

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)

3

Sto lavorando al back-end di un'applicazione web java. Abbiamo un repository di documenti (in particolare Fedora Commons) dove sono ospitati i file xml. Voglio astrarre internamente l'API del repository in modo che non siamo strettamente accoppiati a un prodotto. Mi piacerebbe anche dare la flessibilità di connettersi a un repository tramite Java RMI o API REST. Speravo di ottenere consigli o risorse su come implementare qualcosa di simile.

Pensavo che avrei avuto una classe di repository astratta che aveva metodi come getRecord, updateRecord e deleteRecord. Nel costruttore passerei l'URI per il repository e il metodo e la porta API. Ciò consentirebbe una certa flessibilità in futuro in modo che se l'API REST diventasse più pratica, ma consentisse la flessibilità o l'utilizzo di RMI che potrebbe (dovrebbe?) Avere prestazioni migliori.

Sto pensando troppo a questo o sono sulla strada giusta?

design java api rest

posta user1303881 13.04.2012 - 19:05

fonte

3 risposte

Leggi altre domande sui tag design java api rest

Combinazione di file sorgente, come i file di intestazione Reflection e LGPL

score 3 · Answer 1

Considera questo consiglio per quello che vale, ma ti invito vivamente a riconsiderare l'uso dell'API REST anziché di RMI Java.

Senza disporre di metriche solide per il confronto, sospetto strongmente che le prestazioni tra Java RMI e REST siano simili.

Java RMI è una tecnologia obsoleta che non è così ampiamente adottata.
Altri sviluppatori Java probabilmente hanno esperienza con REST e servizi web rispetto a RMI.
I client del tuo server sono legati alla tecnologia Java (ad esempio, pensa l'espansione ai client mobili)
Problemi di sicurezza

Questi sono solo alcuni dei problemi che ne derivano. Oltre a ciò, dover eseguire il debug delle applicazioni RMI legacy scritte male è stata per me una terribile prova che mi ha segnato la vita mentalmente ed emotivamente. Questo potrebbe farmi un po 'di pregiudizio.

score 2 · Answer 2

Penso che tu sia sulla strada giusta.

Non c'è niente di sbagliato nel mettere un livello di astrazione su un'API di terze parti. In realtà è un'ottima idea. Ad un certo punto, potresti voler sostituire quell'API con un'altra API di terze parti e dovrai solo modificare il tuo livello di astrazione, invece dell'intera applicazione.

Ora, ammettiamolo, questo è uno scenario ideale. La verità è che probabilmente finirai bloccato in quel fornitore per altri motivi. Ma, comunque, dovresti comunque disegnare in questo modo in quanto è una buona pratica.

score 1 · Answer 3

Considera l'utilizzo di OData e REST per l'esposizione dei dati

Ci sono molte informazioni utili sul sito web OData riguardanti come esporre i dati che qualsiasi client compatibile con OData può interpretare e utilizzare. OData è basato su standard Internet come AtomPub, JSON, XML ecc e fornisce una raccolta di utili linee guida su come strutturare gli URI e così via. Esistono client OData per Java, iPhone, PHP, Python, C # e molti altri in modo da non limitare l'accessibilità a un linguaggio di programmazione specifico.

L'approccio OData è compatibile con una architettura RESTful in questo gli URI sono individuabili e il principio HATEOAS è seguito bene. C'è un brivido iniziale quando si impara che Microsoft è dietro di esso, ma questo scompare quando si vede che è in realtà un protocollo aperto che viene utilizzato da persone come Netflix e altri.

Mostrami il codice

In termini di un'API praticabile, dai un'occhiata a codice di esempio da odata4j . Noterai che non espone le sottostanti chiamate REST e invece lavora con i metadati che può derivare esplorando ciò che è stato offerto dall'archivio dati. Ciò rende il client resiliente alle modifiche, come l'aggiunta di nuovi tipi di dati e le relazioni tra loro e tipi di dati esistenti.