Stabilire un'API per fornire accesso app / script agli utenti finali a più tipi di database

5

Domanda e contesto

Attualmente sto lavorando a un progetto in cui la domanda principale è: come inseriamo un'API tra il database e gli utenti finali che potrebbero sviluppare applicazioni / script propri che funzioneranno con o sopra il database?

Il tipo di database con cui lavoro è Postgresql e questo progetto è in-house, quindi gli utenti finali sono utenti di altri gruppi di sviluppo.

Finalità

Quello che sto cercando di soddisfare sono i seguenti:

  • Evita un'interfaccia estesa.
  • Richiede l'autenticazione dall'applicazione che deve utilizzare l'API - fornire all'utente finale un singolo token o chiave univoco per accedere all'applicazione. Nessuna gestione utente / password.
    • Avere la possibilità di renderlo aperto - nessuna autenticazione richiesta.
  • Permetti agli utenti di creare e leggere i record.
  • Limita gli utenti dall'eliminazione e dall'aggiornamento di record esistenti.
  • (Facoltativo) Tieni traccia di chi sta utilizzando l'API: numero di richieste, record, ecc.
  • (Facoltativo) Tieni traccia del tempo trascorso a completare una richiesta.

Alcuni pensieri

Il mio pensiero iniziale è quello di stabilire un'API RESTful costruendo il mio servlet per gestire le richieste e, naturalmente, personalizzarlo per raggiungere i miei obiettivi. Tuttavia, ho la sensazione che ci siano già molte versioni di questa ruota, quindi vorrei evitare di reinventarlo.

Un'ulteriore domanda a questo sarebbe, che cos'è questo tipo di API / livello chiamato (oltre a DAL)?

Aggiornamento

Come sarebbero i vantaggi di mettere in atto un'API comune se ci sono più database di vari tipi, ad es. postgres, ms sql, oracle, ecc.?

    
posta hulkmeister 09.01.2013 - 02:06
fonte

3 risposte

5

My initial thought is to establish a RESTful API by building my own servlet to handle the requests, and of course, customize it to meet my aims. However, I have a feeling there are already many versions of this wheel out there so I would like to avoid reinventing it.

Probabilmente ci sono ma le API REST sono come gli ORM del database, possono potenzialmente accelerare lo sviluppo un po 'ma vengono con il sovraccarico e la maggior parte del lavoro sarà ancora focalizzata nella definizione delle interfacce.

La soluzione migliore è scegliere una piattaforma server di basso livello che ti permetta di controllare routing, richieste e risposte direttamente (es. URI + GET / POST / PUT / DELETE).

In effetti, se si impiega un po 'di tempo a leggere l'approccio HATEOAS alle API REST, inizierai a rendersi conto di quanto REST sia semplice e potente se pienamente utilizzato. Resisti all'impulso di usare anti-pattern REST hackerati in stile Ruby.

Aggiornamento:

Ecco un link valido per alcuni buoni esempi di anti-pattern REST.

Per anti-pattern REST in stile Ruby mi riferisco alla creazione inutile di URI per azioni specifiche.

Per l'URI:

// a URI representing a post
example.org/post/456
// another URI representing a post edit
example.org/post/456/edit

Al contrario di usare POST (cioè creare), PUT (cioè aggiornare), DELETE (cioè rimuovere).

Un altro esempio è l'anti-pattern del blog:

// filter by date
example.com/posts/2012/12/1/
// load by ID
example.com/posts/id/456
// load by title
example.com/posts/title/example-post-title

Fondamentalmente, cosa sta cercando e restituendo la prima istanza che corrisponde ai parametri della data. Il modo RESTful di fare un filtro è usando una querystring sull'URI.

// the post uri represents a post
example.com/post/456
// the posts uri represents a filtered list of posts
// think of a filtered ATOM feed
example.com/posts?date=12/12/1
example.com/posts?title=example-post-title

Ruby è stata una delle prime piattaforme diffuse che ha permesso di creare schemi di routing personalizzati / avanzati senza configurazioni oscure come mod_rewrite di apache. Sfortunatamente, al momento molte persone hanno iniziato a prendere in considerazione schemi di routing personalizzati RESTful quando poi non seguono realmente la definizione.

L'idea è che ci dovrebbe essere un singolo URI che rappresenta ogni risorsa. Le risorse vengono create tramite POST, aggiornate tramite PUT, lette / filtrate tramite GET, ecc. L'incanalamento di tutto tramite GET / POST e / o la creazione di URI per rappresentare azioni su altri URI sono comuni ma non ideali.

Le trasformazioni possono essere gestite usando i tipi MIME:

example.org/post/456+json

Nota: Inoltre, non dimenticare di inviare la risposta con il Content-Type corretto nell'intestazione in modo che il client sappia come gestirlo. In questo caso il Content-Type sarebbe 'application / json'.

L'autenticazione può essere molto semplice se non hai bisogno di un ACL complicato. Basta creare una classe di base Controller in cui le richieste POST / PUT / DELETE richiedono tutte l'autenticazione. Le richieste GET sono generalmente di sola lettura.

Le differenze possono sembrare banali ma immaginare REST come interfaccia di classe. Si prevede che tutto ciò che lo eredita agisca in modo conforme alla definizione dell'interfaccia. Rompere il modello significa rompere il contratto di interfaccia a quel punto l'astrazione perde. Ogni anti-pattern implementato dovrà quindi essere re-implementato su ogni client e l'interfaccia diventerà specifica per l'implementazione.

Optional:

Monitoraggio Analytics:

Il monitoraggio è altrettanto semplice. Imposta un URI per il tracker configurato per accettare le richieste POST. Quando invii la risposta all'utente, invia una seconda risposta all'URI del tracker con le informazioni sull'agente dell'utente nel corpo.

// POST tracking info to this URI with user agent info in the body
example.org/tracking/

Richiedi tracciamento temporale:

Questo dipende davvero. Volete che il tempo dalla richiesta sia ricevuto dal server e una risposta sia inviata? In questo caso, contrassegna semplicemente Date.now () all'inizio del controller, fallo di nuovo dopo che la risposta è stata inviata e confronta i due.

    
risposta data 09.01.2013 - 02:43
fonte
3

Può sembrare irriverente, ma non è così. Perché non usare SQL.

Copre tutte le basi dei tuoi requisiti.

Avoid a wide-interface.
       -- SQL is wide by default but there are some tricks you can use to narrow it down.
Require authentication from the application that is to use the API.
       -- Postgres comes with strong authentication and fine grained security.
Allow users to create and read records.
       -- Just "GRANT" them the privilege.
Restrict users from deleting and updating existing records.
       -- Do not grant them the privilege.
(Optional) Track who is using the API - number of requests, records, etc.
       -- Postgres will log most of this.
(Optional) Track amount of time spent completing a request.
       -- Possible with some low level trickery.

Se segui questa strada, ti consiglio vivamente di esporre solo le visualizzazioni ai tuoi utenti esterni. In effetti dovresti considerare le viste come una definizione di interfaccia, che ti consentirebbe di modificare l'implementazione sottostante senza influenzare gli utenti.

    
risposta data 09.01.2013 - 04:22
fonte
0

<answer>

Sono in ritardo alla domanda, ma farò eco a ciò che ha detto James Anderson: implementare una sorta di data warehouse potrebbe essere un'opzione migliore.

Passare attraverso i database esistenti e modellare le informazioni in modo coerente che tutti i gruppi possono utilizzare. ( Stavi già progettando un po 'di questo lavoro durante la creazione dell'API. Cambia il tuo modo di pensare dagli oggetti alle relazioni. )

Pensa da un'intera prospettiva organizzativa, con software attuali e passati. Potresti avere tipi di entità / dati che hanno determinati elementi in cui un sistema è padrone di una parte dell'entità e un altro è padrone rispetto ad altri aspetti. (ad es. Il sistema Student è padrone di tutti gli archivi degli studenti, ma il sistema di trasporto conosce tutti gli autobus che possono viaggiare ).

Modella tutti i dati per adattarli allo stesso database, il più vicino al formato nativo per le informazioni per il sistema master di questi dati (ad es. Il sistema studente ha 1 campo per un numero di bus, ma il trasporto categorizza 4 diversi bus per uno studente )

Crea viste che possono essere utilizzate per leggere i dati. Mantenere i dati in un database separato rende gli aggiornamenti e le eliminazioni non un'opzione. Hai pieno controllo su quali utenti hanno accesso a cosa.

Non ho una risposta semplice per consentire agli utenti di creare nuovi record o monitorare l'utilizzo e il tempo di risposta. Per creare record, forse una combinazione di creazione di regole o triggers per aggiornare il DB di origine utilizzando dblink o postgres_fdw potrebbe realizzare ciò che desideri. Analytics consisterebbe nel guardare i log.

Altre cose da considerare - Tutti i tuoi gruppi di sviluppatori sanno come lavorare con una risorsa basata su REST (o qualsiasi altra cosa la tua API utilizzerà)? - Puoi trasferire i dati in Excel con la tua API? Esiste un enorme ecosistema costruito attorno a report, estrazione dei dati, business intelligence utilizzando strumenti basati su SQL.

</answer>

Sidebar

In base all'aggiornamento, penso di avere un problema simile a quello nella mia organizzazione e stavo per pubblicare una domanda a parte. Ero propenso a scrivere un sacco di API usando i servizi basati su Apache Thrift che hanno la "conoscenza" di come interrogare diversi elementi di dati nel modo giusto. Il mio ragionamento era:

  • Gli script non avrebbero bisogno di combattere con i driver DB dal momento che userebbero il servizio. Particolarmente importante se volevo provare una lingua diversa che non ha implementato il driver DB. (NodeJS e Go funzionano con Thrift, non riesco a far funzionare i driver Oracle su Windows)
  • Potrei avere un modo standard per estrarre elementi di dati da più versioni del fornitore della nostra linea principale di applicazioni aziendali (2 conversioni software con un tempo di implementazione di 6 mesi nell'arco di 4 anni rendono difficile la ricerca di dati storici)

La mia risposta riflette il motivo per cui mi sto stabilendo sull'approccio basato su SQL. L'API sarebbe la fase 2 del progetto.

    
risposta data 11.02.2014 - 17:30
fonte

Leggi altre domande sui tag