Quadro rubino per scrivere un'API in?

Question

Ciao Sto cercando di scrivere un'applicazione di task multipiattaforma per tecnici. Voglio gestire quante più piattaforme possibile (web, shell, desktop) e quindi ho deciso di iniziare con un server/API.

Voglio scriverlo in Ruby, tuttavia penso che Rails sia un po 'troppo pesante per questo, anche se farebbe il lavoro. Anche Sinatra non sembra abbastanza adatto per questo compito.

Tutto ciò che il server/API farebbe sarebbe quello di tradurre richieste semplici alle query del database e, in una fase successiva, di autenticazione e autorizzazione.

Quindi, fondamentalmente voglio sapere:

1) Devo usare un'API REST o SOAP?

2) Esiste un quadro per questo? O qual è la struttura più vicina disponibile?

Answer 1

Per i più avventurosi, c'è anche un progetto meno noto chiamato grape. È un'applicazione basata su rack, simile a Sinatra, ma è progettata solo per scrivere API. Non penso che sia abbastanza maturo per essere usato in progetti seri, ma è comunque interessante sapere.

Answer 2

1) REST, SOAP è un sistema terribile e il suo supporto in Ruby è piuttosto carente. REST, d'altra parte, è fondamentalmente il default di ruby ​​e richiede pochissimo sforzo da usare, specialmente se si utilizza REST/JSON.

2) Sinatra e Rails sono fondamentalmente le tue opzioni. Si tratta di quanto complessa sarà questa applicazione. Sinatra può probabilmente gestire l'operazione bene, ma Rails fa molto del lavoro per te a scapito di gonfiare. Se utilizzi ActiveRecord per il database, ti ritroverai già a gonfiare alcuni dei binari. Quando entrano in gioco l'autenticazione e/oi ruoli, Rails ha soluzioni mature per entrambi. Senza ulteriori informazioni, mi rivolgo a Rails perché fa molto del lavoro per te e, se scritto correttamente, può ancora essere abbastanza veloce.

Answer 3

In realtà SOAP è molto MOLTO facile da implementare con AWS. Allo stesso tempo, l'API REST è anche molto facile da implementare. Ho scritto un paio di API diverse e parallele (JSON, XML e formato personalizzato) con binari. Sono sicuro che le prestazioni dello stack del framework non saranno il collo di bottiglia, quindi non preoccuparti di preoccuparti delle prestazioni. Il tuo primo collo di bottiglia sarà comunque database e quindi forse richieste al secondo.

Tutto sommato, suggerirei di andare con Rails, ha un sacco di lavoro da ritagliare.

Answer 4

Dal momento che questo thread precedente risulta ancora elevato nelle ricerche Google correlate, dovrei sfruttare la mia raccomandazione fortemente polarizzata (come co-autore e utente) per Hoodoo. A differenza di altre offerte, Hoodoo include uno API specification che dice come devono essere fatte le chiamate API e come devono rispondere; rafforza la coerenza del tuo progetto che i client chiamanti apprezzeranno. Se puoi chiamare una API, puoi chiamarli tutti. Hoodoo implementa gran parte del boilerplate in modo che tu possa concentrarti su un significativo codice di servizio.

Abbiamo utilizzato i servizi di Hoodoo per oltre due anni con grande successo presso Loyalty New Zealand, che gestisce il più grande programma di fidelizzazione del paese. La nostra piattaforma di microservizi basata su Hoodoo gestisce il 100% delle transazioni dei nostri clienti.

• http://hoodoo.cloud/
• https://github.com/LoyaltyNZ/hoodoo
• https://github.com/LoyaltyNZ/hoodoo/tree/master/docs/api_specification
• https://github.com/LoyaltyNZ/service_shell

Hoodoo ha una copertura copertura di test RSpec e il 100% della documentazione rdoc non banale al 100%. Come vedrai dai link qui sopra, c'è parecchio da fare!

Hoodoo è un Rack application, quindi funziona con qualsiasi server Web compatibile con Rack. Il nostro meccanismo di distribuzione preferito è tuttavia un arrangiamento scalabile a tempo indefinito basato su un HTTP-over-AMQP bridge e un cluster AMQP di nodi ciascuno con la stessa raccolta di servizi, gestiti all'interno di contenitori Docker e distribuiti con Fleet. Il sistema esegue l'autocaricamento tra i nodi del servizio tramite la coda e il disaccoppiamento del processore HTTP-> AMQP front-end rispetto all'ingresso AMQP-> HTTP nello stack Rack riduce drasticamente la superficie di attacco del sistema. Abbiamo scritto il componente front-end in Nodo e per ulteriori informazioni su questo insieme alle implementazioni dei nodi di altre parti del concetto di framework, vedere Alchemy Framework. I servizi di Alchemy Node e i servizi di Hoodoo Ruby possono coesistere felicemente sulla stessa rete.