ROAR (Resource Oriented Architecture)

28 Jan

Fast einen ganzen Monat lange habe ich sozusagen den Zirkel zur Seite gelegt und mich mit der technischen Umsetzung der Ginkgo-API in Rails befasst. Die endgültige Wahl des GEMs, was mich dabei unterstützen soll, ist auf ROAR (Resource Oriented Architecture) gefallen. Was hat mich dazu gebracht, ROAR zu nutzen und nicht einen der anderen 6 untersuchten Kandidaten? Im Endeffekt Bidirektionalität!

Mit ROAR werden einfache Ruby-Module definiert, welche das Erscheinungsbild der vom REST-Service gelieferten Repräsentationen bestimmen:

module ProfileRepresenter
include Roar::Representer::JSON

property :name
property :description
property :gender
property :status, :from => :andererName
property :timezone

link :self do
api_user_profile_url user.id
end
end


Falls gewünscht, erweitern diese Representer zur Laufzeit bestehende Model-Klassen und legen sich wie eine Hülle (vgl. Decorator Pattern!) um sie. Wird nun die Repräsentation als JSON (oder auch XML) angefordert, erhalten wir das gewünschte Erscheinungsbild:

{
„name“:“Susanne Hipp“,
„description“:“I am a student.“,
„gender“:“female“,
„andererName“:“student“,
„timezone“:“Guadalajara“,
„links“:[{
{„rel“:“self“,“href“:“http://host/api/users/4f0c41414bb677245a0001f2/profile“}
]}

Das Besondere daran: Dies funktioniert auch bei der „Deserialisierung“, also PUT- oder POST-Anfragen (Diese Richtung unterstützt kein anderes von mir untersuchtes GEM). Diese Funktionalität ist insbesondere wichtig, wenn Felder für die Repräsentation umbenannt wurden (siehe oben :from => andererName). Werden Werte für „andererName“ übergeben, erfolgt modelseitig ein Aufruf des status-Setters.

Momentan läuft es noch nicht ganz wie gewünscht im Zusammenarbeit mit dem in ginkgo genutzt Mongoid-GEM: Problem ist aber erkannt und wird vom Entwickler bald gebannt.

Die API läuft aber schonmal und versorgt Caius ginkgo mobile mit Daten. Ich kann auch recht schnell weitere Ressourcen bereitstellen, falls gewünscht :) .

Nach so viel Programmieren war es dann wieder Zeit etwas zu schreiben… nämlich das Gesamtkonzept für die API. Dies liegt ziemlich vollständig im ginkgo-eigenen Trac und definiert Ressourcen, den Aufbau von Repräsentationen (Felder, Links, Filterkriterien für Liste von Ressourcen) und wie die Kommmunikation mit der API überhaupt stattfinden muss.

Nächste Aktionen: Noch 3 Tage lang Arbeit weiterschreiben und danach OAuth und Autorisierung technisch umsetzen.

Eine Antwort to “ROAR (Resource Oriented Architecture)”

Trackbacks/Pingbacks

  1. Ginkgo API – aber sicher! « Studentenblogs DDI@UPB - 7. Februar 2012

    […] nur änderbare Felder angenommen werden, geschieht über die from_json-Methode des Representers: def update update_attrs = [] if params[:username] update_attrs << :username end if […]

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: