Tag Archives: roar

Konzeption und agile Entwicklung einer REST-Schnittstelle für eine Rails-basierte Scientific Event Management Plattform

23 Apr

Mit der Präsentation ist meine Masterarbeit nun erfolgreich beendet. Ein Konzept, anhand dessen die ginkgo-API komplett entwickelt werden kann, ist im projekteigenen Wiki vorhanden. Der zugehörige Prototyp läuft seit einigen Wochen stabil und setzt Ressourcen in den Bereichen Nutzer, wissenschaftliche Veranstaltungen, private Nachrichten, Kurznachrichten und Activity Stream um.

Die rund 120 Features (dabei handelt es sich um vorhandene und gewünschte Funktionalitäten aus Nutzersicht) waren ein guter Startpunkt, um die für die REST-Schnittstelle benötigten Ressourcen und Repräsentationen herzuleiten.

Kombiniert man das RAILS-Framework mit einer Softwarekomponente, welche die Erstellung der Repräsentationen vereinfacht (z.B. ROAR), ist die Umsetzung einer REST-Schnittstelle sehr elegant möglich.

Mir persönlich hat es sehr viel Spaß gemacht, mit den für mich ganz neuen Technologien Rails und Ruby zu arbeiten und bedanke mich für die Unterstützung aus dem ginkgo-dev-Team!

Hier nun die Folien der Abschlusspräsentation:

 

Werbeanzeigen

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

Weiterlesen

Ginkgo-API: Technische Aspekte

2 Dez

Nachdem ich mich ausreichend in Themen wie API-Erstellung, Authentifizierung, Ressourcenverteilung und Versionierung eingearbeitet habe, gilt es nun, diese theoretischen Erkenntnisse mit den Möglichkeiten, die Rails bietet, abzugleichen.

Rails ist natürlich in dem Sinne „ready for REST“, dass durch ein einfaches respond_to :json, :xml in Controllern und Anpassungen am Routing-Schema Abfragen als JSON/XML funktionieren. Solch ein „out-of-the-box“-Service ist schön, stößt aber für eine saubere REST-Schnittstelle an seine Grenzen:
Weiterlesen