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

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:

 

Ist Rails RESTful?

Obwohl ich zwar nun zum Ende meiner Masterarbeit den theoretischen Teil eigentlich schon abgeschlossen hatte, bin ich auf einen exzellenten Blogpost gestoßen, der schon lange in mir rumorende Fragen zum Thema Rails &REST beantwortet.

Ginkgo API – aber sicher!

Verzeiht mir das kleine Wortspiel… :)

Pünktlich zum Safer Internet Day ist nun eine Möglichkeit gefunden und umgesetzt, um die ginkgo API gegen unberechtigten Zugriff zu schützen.

Die selbst gesteckten Anforderungen waren hart:

• Jede App, die auf die API zugreift, soll erkannt werden (z.B. zwecks Nutzungsauswertungen und Missbrauchsvorbeugung)

• Apps sollen „öffentliche“ Informationen auslesen können, ohne dass ein Nutzer sie dazu autorisiert hätte (Event-Mediastream, Call for Papers)

• Nutzer-spezifische Aktionen sollen nur durch vom Nutzer autorisierte Apps ausgeführt werden können (Freund hinzufügen, Status posten, Nutzerinformationen ändern)

• Apps dürfen keine nur lesbaren oder Systemfelder setzen können (Eventname ändern, Eventcreator ändern)

• Apps dürfen keine „privaten“ Felder auslesen können (E-Mailadresse eines anderen Nutzers lesen)

•  OAuth2.0 -Standard einhalten

Sicherheit ist hier also nicht nur auf Methoden- sondern auch auf Feldbasis zu beachten.

ROAR (Resource Oriented Architecture)

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

Ginkgo-API: Ressourcenstruktur und Aufbau von Repräsentationen

Ich bin alle im Trac gelisteten Features und das Domainmodell nochmals durchgegangen und habe die Adressierung der unterschiedlichen Ressourcen aktualisiert. Je flacher die Ressourcen-Struktur ist, desto weniger Anfragen muss ein Client machen, um an die gewünschte Information zu gelangen.