Skip to content

Instantly share code, notes, and snippets.

@aklassen
Forked from tleilax/ecult-studip-app-api.md
Created October 4, 2012 12:50
Show Gist options
  • Save aklassen/3833351 to your computer and use it in GitHub Desktop.
Save aklassen/3833351 to your computer and use it in GitHub Desktop.
Stud.IP: Anforderungen an eine Schnittstelle zur mobilen Kommunikation

Stud.IP mobil

Schnittstelle für die Kommunikation

Für die mobile Kommunikation ist es erforderlich, dass es eine Schnittstelle gibt, über die Daten aus Stud.IP heraus an einen mobilen Client übertragen werden können. Diese Schnittstelle muss folgenden Anforderungen genügen:

  • sicher (sowohl Nutzerdaten als auch funktional)
  • wesentliche Kernfunktionen müssen abgedeckt werden
  • dokumentiert
  • einfach erweiterbar (schnelle und flexible Anpassungen)
  • schlank (Bandbreiten)

Sicherheit

Für eine Schnittstelle ist es unerlässlich, dass die Sicherheit an folgenden Stellen gewährleistet ist:

  • Nutzervalidierung
  • Übertragung der eigentlichen, möglicherweise sensitiven Daten

Für die Nutzervalidierung empfiehlt sich ein modernes Autorisierungsverfahren wie OAuth, (Wikipedia) bei dem ein tokenbasiertes Autorisierungsverfahren angewendet wird. Token-basiert bedeutet, dass ein Client mit dem Server nicht die Nutzerdaten wie Nutzername und Passwort austauscht, um diesen zu authentifizieren. Stattdessen kann ein Client mit dem Server ein Token aushandeln, welches serverseitig vom Nutzer für den Zugriff auf seine Daten autorisiert werden muss. Dadurch wird gewährleistet, dass die Nutzerdaten den Server im Idealfall niemals verlassen und der Nutzer vollständige Kontrolle über die Nutzung seiner Daten erhält.

Bei der Übertragung der eigentlichen, möglicherweise sensitiven Daten könnte man über eine eigene Verschlüsselung der Kommunikation nachdenken, aber im Endeffekt reicht es, die Kommunikation ausschliesslich via SSL (Wikipedia) zu erlauben. SSL an sich ist ein Verschlüsselungsprotokoll, welches auch heutzutage noch als sicher gilt.

Funktionsabdeckung

Die Schnittstelle muss wesentliche Kernfunktionen des Systems abbilden. Eine grobe Aufzählung ohne Anspruch auf Vollständigkeit könnte folgendermassen aussehen:

  • Nutzerinformationen
  • Nachrichten
  • Kontakte
  • Veranstaltungsinformationen inkl. aktivierter Module
  • Semesterinformationen

Eine vollständige Liste ergibt sich aus dem funktionalen Konzept.

Dokumentation

Für Schnittstellen ist eine vollständige und verständliche Dokumentation essentiell (siehe auch "REST API Documentation Best Practices"). Diese Dokumentation sollte folgende Punkte abdecken:

  • Grundlagen zur Verwendung der Schnittstelle
  • Authorisierung und sonstige Vorbedigungen
  • Strukturierte Übersicht über die bereitgestellten Funktionen:
    • Wie heisst die Funktion und was stellt sie bereit?
    • Wie kann diese Funktion angesprochen werden?
    • Welche (optionalen) Parameter akzeptiert diese Funktion?
    • Welche Rückgabe kann bei Aufruf dieser Funktion erwartet werden?
    • Welche möglichen Fehlerfälle können auftreten?

Erweiterbarkeit

Um flexible Anpassungen an Standorte bzw. Plugins zu erlauben, sollte die Schnittstelle soweit möglich erweiterbar sein. Diese Erweiterbarkeit sollte dabei möglichst einfach gestaltet sein, um unnötige Hürden zu vermeiden.

Schlankheit

Auch wenn die Bandbreiten mobiler Geräte immer weiter steigen, ist die Netzwerkanbindung oftmals noch der Flaschenhals bei mobiler Kommunikation. Aus diesem Grunde sollten die verwendeten Formate zur Kommunikation derart gewählt werden, dass sie einen möglichst geringen Overhead erzeugen.

Aus diesem Grunde sollte eine Schnittstelle primär auf das JSON-Format setzen und das XML-Format nur optional unterstützen (siehe auch "Comparison of JSON and XML Data Interchange Formats: A Case Study").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment