Kategorien
Dienste des ZIM Programmierung

BUW API

Einführung

Die BUW-API ist ein Webservice, um Daten unterschiedlicher Quellsysteme in unterschiedlichen Formaten (TXT, CSV, SOAP, Rest…) in einem einheitlich geordneten Format abrufbar zu machen.
Dadurch wird die Möglichkeit gegeben, verschiedene Universitätsanwendungen Daten austauschen zu lassen, ohne eine eigene vollständige Middleware bauen zu müssen, da die BUW-API flexibel weitere Quellsysteme einbinden kann.
Die Daten können dabei zwischengespeichert oder, soweit dies technisch möglich ist, “live” zur Verfügung gestellt werden.

Daten können öffentlich abrufbar sein, wenn sie grundsätzlich für die Öffentlichkeit von Interesse sein können und keinem besonderen (Daten-)Schutz unterliegen oder erst nach Registrierung über einen API-Key zugänglich sein.

Definition einer API

Allgemeines zu einer API

Eine API, kurz für Anwendungsprogrammierschnittstelle, ist ein Satz von Regeln und Protokollen, die Softwareanwendungen verwenden, um miteinander zu kommunizieren. Sie nimmt Anfragen entgegen und liefert die entsprechenden Antworten zurück. Auf diese Weise können verschiedene Softwareanwendungen effizient zusammenarbeiten und Informationen austauschen.

Wir verwenden eine REST API

Eine REST-API (Representational State Transfer) ist eine Art von API, die auf den Prinzipien des HTTP-Protokolls basiert. Sie verwendet Standard-HTTP-Methoden wie GET, POST, PUT und DELETE, um Daten zu lesen, zu erstellen, zu aktualisieren und zu löschen. Durch die Zustandslosigkeit und die Nutzung von Standard-HTTP-Protokollen ermöglicht sie eine einfache Integration zwischen verschiedenen Softwareanwendungen über das Internet.

Vorteile iner REST API

  1. Einfachheit: REST-APIs verwenden das HTTP-Protokoll und sind daher einfacher zu implementieren und zu verwenden als SOAP, das eine umfangreichere und komplexere Spezifikation hat.
  2. Effizienz: REST-APIs können verschiedene Datenformate wie JSON, XML usw. verwenden, während SOAP nur XML verwendet, was zu größeren Nachrichten und langsamerer Verarbeitung führt.
  3. Skalierbarkeit: Da REST-APIs zustandslos sind, können sie leicht skaliert werden, um eine große Anzahl von Anfragen zu verarbeiten, während SOAP zustandsbehaftete Operationen unterstützt, die schwieriger zu skalieren sind.
  4. Browser-Kompatibilität: REST-APIs können direkt von Webbrowsern aus aufgerufen werden, was sie ideal für den Einsatz in Webanwendungen macht, während SOAP dies nicht nativ unterstützt.

API-Design

Wir verwenden ein Pfad-Format, das die Version der API, den Themenbereich der Daten und eine konkrete Abfrage einschließt, die ggf. durch Parameter weiter spezifiziert werden kann.

Beispiel für eine Response zu einem Call:

{
  "records": [
    {
      "sn": "Willis",
      "cn": "Bruce Willis",
      "givenname": "Bruce",
      "displayname": "Willis, Bruce",
      "gender": "Herr",
      "title": "k.A.",
      "customerid": "bwillis",
      "uid": "ABC-123",
      "mail": [
        "bwillis@uni-wuppertal.de"
      ],
      "telephonenumber": [
        "+492024390000"
      ],
      "mobile": [
        "k.A."
      ],
      "facsimiletelephonenumber": [
        "k.A."
      ],
      "roomnumber": [
        "T.11.00"
      ],
      "o": [
        "ZIM"
      ],
      "labeleduri": [
        "https://uni-w.de"
      ]
    }
  ]
}


API-Dokumentation

Eine komplette Dokumentation steht hier bereit:

https://apic.uni-wuppertal.de/v1/doc/index.php

Nach Registrierung können für jeden User auch individuelle Dokumentationen bereitgestellt werden.

API-Zugriff

Alle Aufrufe sind zurzeit nur aus dem Uni-Netz möglich. Es gibt zurzeit nur zwei öffentliche Aufrufe, für alle anderen ist ein API Key notwendig, der auf Anfrage zugeteilt wird.

Zukunft der APIs

Unser Ziel mit der BUW API ist es, die IT-Systeme unserer Universität weiter zu vernetzen. Wir möchten mehr Schnittstellen für mehr Einrichtungen der Universität verfügbar machen, um eine effizientere und effektivere Kommunikation zu ermöglichen. Eine Grundidee dabei ist es Insellösungen and der BUW – sofern gewünscht – in Zukunft ein Stück weit zu reduzieren. Dies ermöglicht eine bessere Kommunikation und eine einheitliche Datenbasis für Systeme an der BUW bereit zu stellen. Darüber hinaus sind wir bestrebt, öffentliche Informationen der universitären Öffentlichkeit zur Verfügung zu stellen. Im Sinne der Digitalisierung fördern wir die Entwicklung weiterer Anwendungen, die auf diesen Informationen basieren, als ein weiterer wichtiger Schritt in Richtung einer integrierten und digitalisierten Universität ist.

Wenn Sie Interesse an der Nutzung oder Bereitstellung von Daten aus universitären Systemen haben, melden Sie sich gerne unter api at uni-wuppertal.de.

geschrieben von: Florian Siegmund und Tim-Florian Reinartz

Kategorien
PHP Programmierung

Einheitlicher PHP-Code auf Knopfdruck

Ob man alleine an einem Projekt arbeit oder im Team: Code sollte übersichtlich und einheitlich formatiert sein. Fragen wie

  • Kommen geschweifte Klammern ans Zeilenende oder an den Anfang der nächsten Zeile?
  • Werden TRUE und false groß oder klein geschrieben?
  • In welcher Reihenfolge stehen private, public und protected in einer Klasse?

sind durchaus kontrovers. Aber selbst wenn man sich beim Programmieren alle Mühe gibt sämtliche Absprachen einzuhalten, so wird es dennoch Abweichungen geben. Damit ihr dies in PHP-Projekten nicht händisch machen müsst, gibt es ein paar nette Werkzeuge.

Die Tools

Je nachdem ob ihr mit Windows, Linux oder Mac OS arbeitet, verläuft die Installation anders, aber die jeweiligen Projektseiten liefern dazu alles.

Der Workflow

Ihr habt nun zwei Möglichkeiten euren Code überarbeiten zu lassen: innerhalb des Editors oder auf der Kommandozeile. Atom könnt ihr nun automatisch beim Speichern den CS-Fixer ausführen lassen oder ihr macht dies manuell.

Das Ergebnis

Damit ihr wisst warum sich das alles lohnt 😉

Vorher

Nachher

Kategorien
PHP Programmierung WebTech

Umlaute im E-Mail-Header

Um einen Text mit Umlauten zu verschicken reicht i.d.R. die Angabe des Charsets UTF-8 aus:

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Die From-Zeile dieses Headers wird dennoch nicht korrekt dargestellt:

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
From: Geräteausleihe <mail@domain.tld>

Umlaute im Header sind von der Charset-Angabe nicht betroffen und müssen über eine UTF-8-Codetabelle mit Unicode-Zeichen direkt codiert werden:

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
From: =?UTF-8?Q?Ger=c3=a4teausleihe?= <mail@domain.tld>

Erst auf diese Weise wird das ä im Header beim Empfänger korrekt dargestellt.