modo corretto di progettare l'interfaccia REST con nginx lua.

Question

modo corretto di progettare l'interfaccia REST con nginx lua.

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

1

Sono un noob in nginx e lua. Ma sto cercando di progettare un'interfaccia REST.

Il piano è di creare una voce di posizione che corrisponda a URI come questo:

curl -i -X GET 'http://localhost/widgets/widget?name=testname&loc=20000' -H "Accept:application/json"

o

curl -i -X POST 'http://localhost/widgets/widget?name=testname&loc=20000&price=10.12' -H "Accept:application/json"

Voglio restituire dati come questo:

HTTP/1.1 201 Created
Server: nginx/1.6.2
Date: Wed, 25 Feb 2015 13:32:24 GMT
Content-Type: application/json; charset=utf-8

{"name":"testname","loc":"20000","price":"10.12","GET":"http:\/\/localhost\/widgets\/\/widget?name=testname&loc=20000"}

Ciò che ho inventato finora:

All'interno del blocco posizione / contesto, sto andando a testare quale sia il metodo di richiesta (GET vs. POST vs. DELETE) e quindi eseguire la logica all'interno di file lua separati per eseguire tutte le operazioni CRUD. Ad esempio, si noti il seguente codice quasi pseudo:

  #curl -i -X GET 'http://localhost/widgets/widget?name=testname&loc=20000' -H "Accept:application/json"
    location /widgets/widget {
            default_type "text/pain";
            #ifisEvil... unless done inside lua
            content_by_lua '

                    if ngx.var.request_method == 'GET' then
                            add logic to call "read_widget.lua"
                            somehow save results from read_widget.lua in string
                            response.body = results_string
                            convert results_string to json format.
                            return results_string_as_json 
                    elseif ngx.var.request_method = 'POST' then
                            add logic to call "create_widget.lua"
                            same logic as GET...
                    elseif ngx.var.request_method = 'DELETE' then
                            add logic to call "delete_widget.lua"
                            same logic as GET...
                    end
            ';
    }

Domande

È questo l'approccio giusto da prendere? In particolare, è possibile chiamare metodi in file esterni e restituire grandi quantità di dati da loro nel file nginx.conf?
Anche se è possibile, è una buona idea? Questi file esterni conterranno la logica per connettersi all'origine dati, massaggeranno i dati e quindi prepareranno la risposta HTTP corretta ... come 201 per nuove risorse, 404 ecc ecc.

Grazie a tutti.

rest lua

posta Happydevdays 25.02.2015 - 15:16

fonte

2 risposte

0

Se fossi in te, darei un'occhiata a Lapis. È un framework Lua molto leggero e veloce per OpenResty. Mi sono davvero divertito e prevedo che avrà un futuro radioso!

link

Con esso puoi facilmente scrivere un'API REST che restituisce json con codice semplice come:

app:get("list_users", "/users", function(self)
    local users = Users:select() 
    return { json = { users } }
end)

Un post può essere fatto in questo modo:

app:post("/user/new", json_params(function(self)
    self.user = Users:create({
        email = self.params.email,
        password = self.params.password,
        fname = self.params.fname,
        lname = self.params.lname
    })
    return { json = { self.user } }
end))

Gli altri verbi HTTP possono essere gestiti con facilità simile.

Inoltre, come ci si potrebbe aspettare con qualsiasi cosa creata per sfruttare OpenResty, i benchmark di Lapis sono incredibilmente buoni: link

Per l'avvio, l'autore di Lapis ha anche scritto un linguaggio simile a CoffeeScript per Lua chiamato MoonScript che è molto carino @ moonscript dot org

risposta data 10.03.2016 - 21:32

fonte

Leggi altre domande sui tag rest lua

Come memorizzare le informazioni sensibili (ad esempio le credenziali dei clienti) in modo accessibile per tutti all'interno? Traversal di grandi grafici con OOP

score 1 · Accepted Answer

Sì, è un'architettura corretta: il concetto di un server web che accetta le richieste e il passaggio della chiamata a un altro server da elaborare è quasi certamente la migliore pratica in tutti i casi. Almeno teoricamente è possibile quindi ospitare i file logici su uno o più server applicazioni se il carico diventa eccessivo. Anche se questo non si applica a te in questo momento, è comunque buono avere la flessibilità, soprattutto se si finisce per riutilizzare parte di questo codice in futuro.

Tuttavia, scrivi i tuoi file di 'business logic' in modo che non abbiano alcuna comprensione della richiesta http, in modo da restituire i normali codici di errore che sono tradotti in qualcosa di più http-y dal lato del server web delle cose.

Potresti anche vedere un codice di aiuto come lua-resty-rack