Ruby-Framework zum Schreiben einer API? [geschlossen]

8

Hi, ich möchte eine Multiplatorm-Aufgabenanwendung für technische Mitarbeiter schreiben. Ich möchte so viele Plattformen wie möglich handhaben (Web, Shell, Desktop) und habe daher beschlossen, mit einem Server / API zu beginnen.

Ich möchte es in Ruby schreiben, aber ich denke, dass Rails ein bisschen zu schwer dafür ist, obwohl es den Job machen würde. Sinatra scheint auch für diese Aufgabe nicht geeignet zu sein.

Alles was der Server / die API tun würde, wäre, einfache Anfragen in Datenbankabfragen zu übersetzen, und zu einem späteren Zeitpunkt einige Authentifizierungen und Autorisierungen.

Also im Grunde möchte ich wissen:

1) Sollte ich eine REST-API oder eine SOAP-API verwenden?

2) Gibt es dafür einen Rahmen? Oder was ist der nächste verfügbare Rahmen?

    
thomasfedb 20.06.2010, 16:20
quelle

4 Antworten

8

Für die Abenteuerlustigen gibt es auch ein weniger bekanntes Projekt namens Weintrauben . Es ist eine Rack-basierte Anwendung, ähnlich wie Sinatra, aber nur zum Schreiben von API gedacht ist. Ich denke nicht, dass es reif genug ist, um in ernsthaften Projekten verwendet zu werden, aber es ist immer noch interessant zu wissen.

    
Aaron Qian 04.08.2011, 23:33
quelle
5

1) REST, SOAP ist ein schreckliches System und seine Unterstützung in Ruby fehlt sehr. REST hingegen ist im Grunde der Rubin-Standard und benötigt nur sehr wenig Aufwand, insbesondere wenn Sie REST / JSON verwenden.

2) Sinatra und Rails sind grundsätzlich Ihre Möglichkeiten. Es kommt darauf an, wie komplex diese Anwendung sein wird. Sinatra kann die Aufgabe wahrscheinlich gut bewältigen, aber Rails erledigt einen Großteil der Arbeit für Sie auf Kosten von Bloat. Wenn Sie ActiveRecord für die Datenbank verwenden, übernehmen Sie bereits einige der aufgeblähten Rails. Wenn Authentifizierung und / oder Rollen ins Spiel kommen, hat Rails ausgereifte Lösungen für beide. Ohne weitere Informationen würde ich mich Rails zuwenden, da es einen Großteil der Arbeit für Sie erledigt und wenn es richtig geschrieben ist, immer noch ziemlich schnell sein kann.

    
Ben Hughes 20.06.2010 17:12
quelle
1

Eigentlich ist SOAP sehr einfach mit AWS zu implementieren. Gleichzeitig ist die REST API sehr einfach zu implementieren. Ich habe ein paar verschiedene und parallele APIs (JSON, XML und benutzerdefiniertes Format) mit Rails geschrieben. Ich bin sicher, dass die Leistung des Framework-Stacks nicht dein Engpass sein wird, also mach dir keine Sorgen über die Performance. Ihr erster Flaschenhals wird sowieso Datenbank sein und dann vielleicht Anfragen pro Sekunde.

Alles in allem würde ich vorschlagen, mit Rails zu gehen, es hat eine Menge Arbeit für dich rausgeschnitten.

    
Tanel Suurhans 20.06.2010 18:48
quelle
1

Da dieser alte Thread bei verwandten Google-Suchen immer noch hoch ankommt, sollte ich meine sehr voreingenommene (als Co-Autor und Nutzer) Empfehlung für Hoodoo . Im Gegensatz zu anderen Angeboten enthält Hoodoo eine API-Spezifikation , die angibt, wie API-Aufrufe durchgeführt werden müssen und wie sie aussehen muss antworten; Es sorgt für eine Konsistenz in Ihrem Design, die anrufende Kunden zu schätzen wissen. Wenn Sie eine API aufrufen können, können Sie sie alle aufrufen. Hoodoo implementiert eine Menge des Boilerplate, so dass Sie sich auf einen aussagekräftigen Service-Code konzentrieren können.

Wir verwenden die Hoodoo-Dienste seit über zwei Jahren sehr erfolgreich bei Loyalty New Zealand, die das größte Treueprogramm des Landes betreiben. Unsere Hoodoo-basierte Microservice-Plattform wickelt 100% unserer Kundentransaktionen ab.

Hoodoo hat 100% nicht-triviale rspec Testabdeckung und 100% rdoc Dokumentationsabdeckung. Wie Sie den obigen Links entnehmen können, gibt es da eine Menge!

Hoodoo ist eine Rack-Anwendung , die mit jedem Rack-kompatiblen Webserver funktioniert. Unser bevorzugter Bereitstellungsmechanismus ist jedoch eine unbegrenzt horizontal skalierbare Anordnung, die auf einer HTTP-über-AMQP-Brücke und einem AMQP-Cluster von Knoten basiert Jeder führt dieselbe Sammlung von Diensten aus, wird in Docker-Containern verwaltet und mit Fleet bereitgestellt. Das System-Self-Load balanciert über die Wartungsknoten hinweg über die Warteschlange und die Entkopplung des Front-End-HTTP- & gt; AMQP-Prozessors gegenüber dem AMQP- & gt; HTTP-Eingang in den Rack-Stapel reduziert die Angriffsfläche des Systems dramatisch. Wir haben die Frontend-Komponente in Node geschrieben, und dazu mehr über Node-Implementierungen anderer Teile des Framework-Konzepts, siehe Alchemy Framework . Alchemy Node-Dienste und Hoodoo Ruby-Dienste können gemeinsam auf demselben Grid koexistieren.

    
Andrew Hodgkinson 10.01.2017 20:12
quelle

Tags und Links