2014 gnepper,tom entwicklung eines application programming interface, bachelor_thesis

BACHELORTHESIS
zur Erlangung des akademischen Grades
Bachelor of Science (B.Sc.)
im Studiengang Medieninformatik
des Fachbereiches Umweltplanung / Umwelttechnik
Entwicklung eines Application
Programming Interface und des
dazugehörigen
Authentifizierungsprozesses für
Benutzer der Internetpräsenz
www.earthfaves.com
Vorgelegt von: Tom Gnepper
Betreuer: Prof. Dr. phil. nat. Rolf Krieger
Zweitprüfer: Prof. Dr. Martin Rumpler
Abgabetermin: 20. Januar 2014, WS 2013/14

II
Kurzdarstellung
Für die earthfaves AG wurde ein Application Programming Interface (im Folgenden
„API“ genannt) für Geschäftskunden entwickelt. Die API soll den Benutzern die
Möglichkeit geben, auch von externen Anwendungen ausgehend auf ihre Daten
zuzugreifen. Bei der Entwicklung einer API gibt es verschiedenste Aspekte, welche
berücksichtigt werden sollten, damit dem Endnutzer ein möglichst leicht zu
verstehendes und konsistent arbeitendes Werkzeug zur Verfügung gestellt werden
kann. Diese Aspekte reichen dabei von der Datensicherheit bis hin zur Anwendbarkeit
der Schnittstelle für den Benutzer. In dieser Arbeit werden die theoretischen
Vorüberlegungen und die nachfolgende beispielhafte Implementierung in der
Skriptsprache PHP einer API beschrieben.

III
Erklärung des Verfassers
„Ich versichere, dass die vorliegende Arbeit von mir selbstständig und ohne
unerlaubte fremde Hilfe sowie ohne Benutzung anderer als der angegebenen
Hilfsmittel angefertigt wurde. Alle Inhalte, die wörtlich oder sinngemäß aus
veröffentlichten Schriften und anderen Quellen entnommen sind, wurden als
solche gekennzeichnet. Die Arbeit ist in gleicher oder ähnlicher Form noch nicht
als Prüfungsarbeit eingereicht worden.“
.................................................... ..............................................
(Unterschrift des Verfassers) (Ort, Datum)

IV
Inhaltsverzeichnis
Kurzdarstellung ........................................................................................................................ II
Erklärung des Verfassers ..................................................................................................... III
Abbildungsverzeichnis.........................................................................................................VII
Tabellenverzeichnis...............................................................................................................VII
1. Einleitung...........................................................................................................................- 1 -
1.1. Motivation...................................................................................................................- 1 -
1.2. Ziel der Arbeit............................................................................................................- 2 -
1.3. Vorgehensweise .......................................................................................................- 3 -
2. Earthfaves..........................................................................................................................- 3 -
2.1. Unternehmensbeschreibung.................................................................................- 3 -
2.2. Das Netzwerk.............................................................................................................- 4 -
2.2.1. Verbraucherlösung...........................................................................................- 4 -
2.2.2. Unternehmenslösung.......................................................................................- 5 -
3. Technische und konzeptionelle Grundlagen............................................................- 5 -
3.1. Application Programming Interfaces (API)........................................................- 6 -
3.2. Asynchronous JavaScript and XML (AJAX) .....................................................- 7 -
3.3. jQuery ..........................................................................................................................- 7 -
3.4. Extensible Markup Language (XML) ...................................................................- 8 -
3.5. JavaScript Object Notation (JSON) .....................................................................- 8 -
3.6. OAUTH.........................................................................................................................- 9 -
3.7. Hypertext Transport Protocoll (http)...................................................................- 9 -
3.7.1. Allgemeines........................................................................................................- 9 -
3.7.2. http-Methoden..................................................................................................- 10 -
3.8. Hypertext Transport Protocoll Secure (https) ................................................- 11 -
3.9. Model-View-Controller (MVC)..............................................................................- 11 -
3.10. PROPEL ORM........................................................................................................- 12 -
3.11. Architektur und Entwicklungsrichtlinien der Earthfaves AG ...................- 12 -
3.11.1. Architektur......................................................................................................- 12 -
3.11.2. Datenbanken ..................................................................................................- 13 -
3.11.3. Framework......................................................................................................- 14 -
4. Anforderungsanalyse und Design ............................................................................- 15 -
4.1. Anforderungsanalyse............................................................................................- 15 -
4.1.1. Möglichkeiten und Nutzen einer API..........................................................- 15 -
4.1.2. Anforderungen an die API ............................................................................- 17 -

V
4.1.3. Welche Informationen soll die API liefern ................................................- 18 -
4.1.4. Festlegung des Ausgabeformats................................................................- 20 -
4.1.5. Weitere Anforderungen .................................................................................- 21 -
4.2. Design........................................................................................................................- 22 -
4.2.1. Anwendung von MVC und objektorientierter Programmierung.........- 22 -
4.2.2. Ein Controller-Objekt für die Logik ............................................................- 23 -
4.2.3. Ein Model-Objekt für die Datenbank ..........................................................- 23 -
4.2.4. Ein View-Objekt für die Ausgabe ................................................................- 24 -
4.2.5. Ein Controller-Objekt für die Zeitmessung ..............................................- 24 -
4.2.6. http-Methoden und URLs..............................................................................- 24 -
4.2.7. Beschränkung des Zugriffs..........................................................................- 27 -
4.2.8. Ausgabestruktur..............................................................................................- 28 -
4.2.9. Statuscodes......................................................................................................- 29 -
5. Implementierung............................................................................................................- 31 -
5.1. Einrichten der Subdomain ...................................................................................- 32 -
5.2. Erweiterung der Datenbank.................................................................................- 33 -
5.3. Programmierung der Logik im Backend ..........................................................- 36 -
5.4. Erweiterung der Internetpräsenz für Geschäftskunden...............................- 39 -
5.5. Erstellung der Access Token ..............................................................................- 41 -
5.6. Entwicklung einer Administrationsoberfläche ...............................................- 42 -
5.7. Programmdokumentation ....................................................................................- 46 -
6. Test....................................................................................................................................- 47 -
6.1. Test der API..............................................................................................................- 47 -
6.1.1. Informationen zu Personen, die earthfaves empfehlen........................- 47 -
6.1.2. Informationen zu Personen, die earthfaves nicht mehr empfehlen...- 47 -
6.1.3. Informationen zu Personen, die earthfaves explizit nicht empfehlen- 48 -
6.1.4. Informationen zu einem Benutzer...............................................................- 48 -
6.1.5. Informationen zu einem earthfave..............................................................- 49 -
6.1.6. Erhalten eines vorhandenen Access Token ............................................- 49 -
6.1.7. Erhalten eines neuen Access Token..........................................................- 50 -
6.1.8. Fehlercodes......................................................................................................- 50 -
6.1.9. Zeitmessung.....................................................................................................- 52 -
6.1.10. Zusammenfassung.......................................................................................- 52 -
6.2. Test der Administrationsoberfläche..................................................................- 53 -
6.3. Test der Erweiterung der Internetpräsenz für Geschäftskunden..............- 53 -

VI
7. Fazit..................................................................................................................................- 54 -
Literaturverzeichnis...............................................................................................................VII
Verzeichnis der verwendeten Internetquellen................................................................VII
Anhang 1: API-Dokumentation..........................................................................................VIII
Anhang 2: Programmcode..................................................................................................VIII

VII
Abbildungsverzeichnis
Abbildung 1: Beispielhafte Ausgabe der Metadaten.......................................................- 29 -
Abbildung 2: Beispielhafte Ausgabe der Nutzdaten .......................................................- 29 -
Abbildung 3: Beschreibung des URL Rewriting...............................................................- 32 -
Abbildung 4: Datenbankschema aller genutzten Tabellen ............................................- 35 -
Abbildung 5: Ablaufdiagramm des Prüfungsmechanismus zum Zugriff auf die API .- 38 -
Abbildung 6: Erweiterung der Internetpräsenz für Geschäftskunden ..........................- 41 -
Abbildung 7: Administrationsoberfläche – allgemeine Einstellungen...........................- 44 -
Abbildung 8: Administrationsoberfläche – Übersicht der Nutzer der API....................- 45 -
Abbildung 9: Administrationsoberfläche – Übersicht aller Zugriffe auf die API ..........- 45 -
Tabellenverzeichnis
Tabelle 1: Erklärung aller Statuscodes und der dazugehörigen Beschreibungen .....- 31 -
Tabelle 2: Ausgabe des Aufrufs zu Empfehlern eines earthfaves................................- 47 -
Tabelle 3: Ausgabe des Aufrufs zu ehemaligen Empfehlern eines earthfaves.........- 48 -
Tabelle 4: Ausgabe des Aufrufs zu Personen, die einen earthfave explizit nicht
empfehlen..............................................................................................................................- 48 -
Tabelle 5: Ausgabe des Aufrufs zu einem Benutzer.......................................................- 49 -
Tabelle 6: Ausgabe des Aufrufs zu einem earthfave......................................................- 49 -
Tabelle 7: Ausgabe des Aufrufs zu einem Access Token..............................................- 49 -
Tabelle 8: Ausgabe des Aufrufs zum Erhalt eines neuen Access Token....................- 50 -
Tabelle 9: Fehlerhafte Aufrufe der API .............................................................................- 51 -
Tabelle 10: Zeitmessung der Funktionalitäten der API ..................................................- 52 -

- 1 -
1. Einleitung
1.1. Motivation
Der Begriff API, ausgeschrieben „Application Programming Interface“, dürfte selbst
versierten Nutzern des World Wide Web, welche keine Programmierkenntnisse haben,
innerhalb der letzten Jahre mehrfach zu Ohren gekommen sein. In Zusammenhang
wird der Begriff mit Konzernen wie Facebook gebracht, welche über eben solche
Schnittstellen Daten für externe Applikationen zur Verfügung stellen.
Eine API stellt somit eine Schnittstelle zwischen zwei Anwendungen her und liefert die
Möglichkeit, Daten auszutauschen. Dies findet im Regelfall zwischen einem Provider
(zu Deutsch: Anbieter), welcher die Daten zur Verfügung stellt, und einer Anwendung,
welche die Daten über einen Aufruf einer Methode der API bezieht und diese weiter
verarbeitet, statt. Im Fall einer API eines sozialen Netzwerks dient die API
hauptsächlich dem Beziehen von Informationen über Benutzer des sozialen
Netzwerks. Statistischen Erhebungen zufolge gilt die Nutzung von APIs im Bereich
sozialer Netzwerke als einer der größten Anwendungsbereiche.1
Neben diesen APIs existiert jedoch eine Vielzahl weiterer Schnittstellen für Bereiche
wie Shopping, Musik oder Telefonie.2
Die Internetpräsenz
http://www.programmableweb.com/, welche eine der größten Sammelquellen für APIs
ist und Informationen zum Thema liefert, listete im Sommer 2005 gerade einmal 32
APIs.3
Zu erkennen ist also, dass das Thema der APIs zumindest im World Wide Web
noch nicht lange von Bedeutung ist, auch wenn die Entwicklung von und mit APIs
schon auf die Anfänge der Programmierung zurückgeht. Schon die Erstellung eines
Programms für ein gewisses Betriebssystem nutzt eine Schnittstelle zur Erstellung und
zum Ablauf.
Inzwischen, Ende 2013, listet programmableweb schon mehr als 10.000 APIs, was
zeigt, dass sich gerade in den letzten Jahren ein starkes Aufkommen neuer APIs
verzeichnen lässt.4
Nicht zuletzt wird dies auch durch die kontinuierliche
Weiterentwicklung von Webstandards wie TLS, welches eine verschlüsselte
Übertragung ermöglicht, unterstützt.
1
Vgl. http://fredonfire.com/2011/10/the-increasing-importance-of-apis-in-web-development/.
2
3
4
Vgl. http://www.programmableweb.com/.

- 2 -
Die Earthfaves AG bietet ein Netzwerk an, in welchem Benutzer sogenannte
earthfaves anlegen können. Earthfaves können Naturschauplätze, Geschäfte oder
ähnliche Orte sein. Geschäftskunden der Earthfaves AG ist es möglich, mit Empfehlern
des eigenen earthfaves in Kontakt zu treten. Aus diesem Grund werden dem Kunden
statistische und kommunikative Werkzeuge auf der Internetpräsenz gegeben. Diese
Funktionalitäten sollen um eine API erweitert werden, so dass die Kunden ihre Daten
auch extern nutzen können. Ein möglicher Anwendungsfall ist, dass ein Kunde alle
Kommentare der Empfehler in einer eigenen Anwendung veröffentlichen möchte.
Nachfolgend soll nun betrachtet und erklärt werden, was genau eine API auszeichnet
und wie diese beispielhaft implementiert werden kann. Ebenfalls sollen dafür
notwendige und hilfreiche Technologien und Konzepte betrachtet werden.
1.2. Ziel der Arbeit
Ein vollständig funktionsfähiges Application Programming Interface zu erstellen und zu
dokumentieren ist das Ziel der vorliegenden Arbeit. Dabei sollen, neben der
Programmierung der eigentlichen API, eine Administrationsoberfläche und eine
Erweiterung für das Menü für Geschäftskunden der Internetpräsenz
www.earthfaves.com entwickelt werden.
Die API soll die Form einer serverseitigen Web-API haben, was an späterer Stelle
erläutert wird, verkürzt aber bedeutet, dass Daten über ein Transportprotokoll wie http
per Anfrage an eine URL zurückgegeben werden. Dementsprechend müssen
verschiedene URLs für das Abfragen verschiedenster Daten definiert werden.
Die Administrationsoberfläche soll ein Werkzeug zur Verfügung stellen, welches es
ermöglichen soll, die wichtigsten Eigenschaften und Einstellungen der Schnittstelle
umfassend und schnell zu ändern.
Damit den Benutzern auch die Möglichkeit gegeben werden kann, die API zu nutzen,
soll die Erweiterung im Menü für Geschäftskunden alle dafür notwendigen Daten
enthalten.
Die im Titel dieser Arbeit erwähnten Benutzer werden ausschließlich Geschäftskunden
der Internetpräsenz www.earthfaves.com sein. Das beschriebene Design und die
daraus folgenden Implementierungen sollen also keine öffentlich zugängliche
Schnittstelle darstellen.

- 3 -
Zuletzt soll noch eine öffentlich zugängliche Dokumentation für die Benutzer der API
erstellt werden, um diesen zu erklären, in welcher Art die API zu nutzen ist,
beziehungsweise welche Möglichkeiten ihnen diese bietet.
1.3. Vorgehensweise
Die Arbeit gliedert sich hauptsächlich in vier Teilaspekte. Der erste geht kurz auf die
Earthfaves AG und das dazugehörige Netzwerk ein. Die theoretische Betrachtung aller
notwendigen Kenntnisse und Informationen zu benutzten Technologien wird im zweiten
Teil der Arbeit betrachtet. Der dritte Teil beschreibt die praktische Durchführung,
sprich: die Programmierung. Zuletzt folgen das Testen der zuvor erstellten API und
eine kurze Auswertung.
Da es im Laufe der Implementierung zeitweise zur Überarbeitung und zur Erstellung
eines neuen Designs gekommen ist, wird bei der Beschreibung in dieser Arbeit nicht
die chronologische Reihenfolge der Arbeitsschritte eingehalten. Vielmehr ist sie als
Leitfaden für diejenigen Implementierungen zu verstehen, welche letztendlich auch in
der finalen Version enthalten sind. Kleine Änderungen werden aus diesem Grund nicht
aufgeführt, größere jedoch schon.
2. Earthfaves
2.1. Unternehmensbeschreibung
Die Earthfaves AG ist ein 2007 gegründetes Startup Unternehmen mit dem Ziel, das
weltweit erste Netzwerk basierend auf Lieblingsorten und deren Empfehlungen
aufzubauen. Die Mitarbeiter betreiben die Internetpräsenz www.earthfaves.com und
entwickeln diese stetig weiter.
Der Hauptstandort der Earthfaves AG befindet sich in Saarbrücken, wo die Bereiche
Marketing und Entwicklung bearbeitet werden. Weiterhin existiert der Aufgabenbereich
Design, welcher in Berlin bearbeitet wird.

- 4 -
2.2. Das Netzwerk
Das Netzwerk earthfaves versteht sich als ein Ort, an dem Benutzer ihre
Empfehlungen über gewisse Orte aussprechen und diese mit ihren Freunden und
Freundesfreunden teilen können. Der Name earthfaves lässt sich aus der Phrase
„favorite places on earth“ herleiten. „Earthfaves“ sind also die Orte, zu welchen die
Empfehlungen ausgesprochen werden. Das Netzwerk bietet sowohl eine Lösung für
„normale“ Benutzer als auch eine Lösung für Unternehmen.
2.2.1. Verbraucherlösung
Als Benutzer der Internetpräsenz www.earthfaves.com besteht die Möglichkeit, beliebig
viele earthfaves anzulegen und diese mit Freunden zu teilen. Das Ziel ist es dabei,
seinen Freunden und Freundesfreunden nur die besten Orte und Unternehmen
mitzuteilen. Bei diesem Vorgang spricht man vom „Faven“, also dem Anlegen eines
Favoriten. Erst das Anlegen und Teilen von earthfaves innerhalb seines persönlichen
Netzwerkes führt dazu, dass sich manche Orte und Unternehmen im gesamten
Netzwerk herumsprechen und somit bekannter werden.
Ein weiteres Konzept, welches als „Waven“ bezeichnet wird, erweitert das Prinzip des
Favens um den Aspekt weiterer Endpunkte. Als Endpunkte sind dabei beispielsweise
weitere soziale Netzwerke zu verstehen. Einem Benutzer ist es möglich, sich mit
verschiedenen Netzwerken zu verbinden. Dadurch entsteht, insofern man einen Favorit
empfiehlt, eine wesentlich höhere Reichweite beim Empfehlen, wodurch eine größere
Anzahl an Rezipienten erreicht werden kann.
Vor allem der Aspekt der Empfehlungen durch Personen, welche in enger Beziehung
zu einem Benutzer stehen, steht bei www.earthfaves.com im Vordergrund. Persönliche
Empfehlungen von Personen, die einem Benutzer persönlich bekannt sind, haben eine
höhere Aussagekraft über ein Unternehmen, als Werbung, welche durch Unternehmen
produziert wird. Weiterhin sind diese wichtiger als Empfehlungen, welche fremde
Personen freigeben.
Stehen „normale“ Benutzer in Beziehung zu einem Geschäftskunden, so lassen sich
diese in drei Gruppen aufteilen. Zum einen ist dies der Empfehler, welcher aktuell den
earthfave empfiehlt. Des Weiteren gibt es Personen, die einen earthfave nicht mehr
empfehlen und deshalb einen Kommentar hinterlassen, aus welchem Grund sie ihn
nicht mehr empfehlen. Zuletzt existieren noch Personen, die einen earthfave explizit

- 5 -
noch nicht empfehlen und dem Geschäftskunden daher einen Verbesserungsvorschlag
mitteilen.
2.2.2. Unternehmenslösung
Das Ziel für Unternehmen bei der Nutzung ist, die eigene Bekanntheit zu steigern und
eine nachhaltigere Kundenbindung zu erzielen. Dabei ist vor allem wichtig, dass ein
Unternehmen nachvollziehen kann, aus welchen Gründen es empfohlen wird.
Dementsprechend bedeutsam ist aber auch, aus welchen Gründen das Unternehmen
nicht empfohlen wird. Es sollen also sowohl die Stärken als auch die Schwächen eines
Unternehmens aggregiert und zusammengefasst werden.
Empfiehlt ein Kunde das Unternehmen und teilt es anhand des Erstellens einer „Wave“
in viele Netzwerke, so profitiert demzufolge auch das Unternehmen, weil der Kreis an
potentiellen Neukunden sehr hoch ist.
Um zufriedenen Kunden mehr Nähe zum Unternehmen aufzuzeigen, ist es möglich,
sogenannte Lovebacks anzubieten, welche dem Empfehler einen Treue-Bonus
anbieten. Lovebacks liegen in Form verschiedenster Sonderangebote vor. Ebenfalls
können Kickbacks angeboten werden, welche einem Empfehler beispielsweise nach
dem Einkauf einen gewissen Rabatt ermöglichen. Um das Netzwerk eines Empfehlers
anzusprechen und Neukunden zu gewinnen, kann der Geschäftskunde den Freunden
eines Empfehlers Angebote zukommen lassen.
3. Technische und konzeptionelle Grundlagen
In diesem Kapitel werden einige wichtige Begriffe, Technologien und Konzepte erklärt,
welche für die Entwicklung der API und der dazugehörigen Anpassungen auf der
Internetpräsenz www.earthfaves.com notwendig oder von Nutzen gewesen sind.
Weiterhin werden neben einer allgemeinen theoretischen Betrachtung und einer
kurzen Einführung in die Themengebiete auch die Entwicklungsrichtlinien der
earthfaves AG erklärt. Die Kenntnis darüber ist für die Erweiterung der Internetpräsenz
notwendig. Auf eine Erklärung grundlegender Techniken, wie HTML und Ähnliches,
wird verzichtet.

- 6 -
3.1. Application Programming Interfaces (API)
Wie schon in der Motivation dieser Arbeit erwähnt, gilt es erst einmal herauszustellen,
was genau eine API ist. Hierbei wird vorerst rein auf die technischen Details einer API
eingegangen. Welchen Nutzen eine API, insbesondere einem Unternehmen, bietet,
wird an späterer Stelle in dieser Arbeit erläutert.
Eine API stellt dem Anwender gewisse Funktionalitäten, Methoden und Daten zur
Verfügung, die ihm unter normalen Umständen nicht zugänglich wären. Das bedeutet,
dass eine API eine Schnittstelle zwischen zwei oder mehreren Soft- oder
Hardwarekomponenten darstellt. In vielen Fällen werden so Daten zwischen
verschiedenen Anwendungen oder auch Servern ausgetauscht. Ein Beispiel hierfür ist
die bereits erwähnte Facebook-API, über welche ein Programm Informationen zu
gewissen Personen aus der Facebook-Datenbank auslesen und diese
weiterverarbeiten kann. Auch andersherum ist das Senden von Daten vom Client –
also dem Programm – zum Provider – in diesem Fall Facebook – möglich, indem
beispielsweise Status-Updates5
per Anfrage an Facebook übermittelt werden können.
Ein anderer Anwendungsfall ist die Windows-API. Diese eröffnet dem Entwickler die
Möglichkeit, Anwendungen für das Betriebssystem „Windows“ der Microsoft
Corporation zu erstellen. Hierbei stehen allerdings keine Informationen im Mittelpunkt,
welche über die Schnittstelle ausgetauscht werden könnten, sondern allein die
Bereitstellung der Funktionalitäten zur Erstellung einer solchen Anwendung. Es werden
Methoden zur Erzeugung der „Windows“ und weiterer Steuerelemente zur Verfügung
gestellt, wobei es dem Programmierer überlassen bleibt, diese zu modifizieren und mit
weiterem Programmcode zu hinterlegen. Die API bietet folglich nur das Grundgerüst,
woraus der Anwender eine vollkommen eigene Anwendung bauen kann.
Die API, welche im Verlaufe dieser Arbeit beschrieben und dokumentiert wird, stellt
eine Web-API dar. Web-APIs unterscheiden sich im Grunde nicht von der Struktur
anderer APIs. Zu beachten ist hierbei jedoch, dass in den meisten Fällen das Nutzen
der API rein über die Eingabe einer URL gesteuert wird. Methoden, welche dabei
genutzt werden, beschränken sich zumeist auf die Methoden, die vom Protokoll http
vorgesehen sind und in einem späteren Kapitel erläutert werden.
5
Ein Status-Update bezieht sich hierbei konkret auf das Netzwerk www.facebook.com, welches es
ermöglicht, Inhalte und Nachrichten mit anderen Benutzern zu teilen.

- 7 -
3.2. Asynchronous JavaScript and XML (AJAX)
„Asynchronous JavaScript and XML“ ist ein Konzept, welches es ermöglicht, asynchron
Daten zwischen dem Client und dem Server zu übertragen. Im Wesentlichen bedeutet
das, dass Inhalte einer Seite partiell und ohne komplettes Neuladen der Seite geändert
werden können. Anwendungsbeispiele sind gerade im Zusammenhang mit HTML5
Browserspiele, die auf das neue Canvas-Element zurückgreifen. Das Canvas-Element
stellt eine Leinwand dar, auf welcher man unter Zuhilfenahme von JavaScript 2D- und
3D-Objekte rendern und darstellen kann.6
Bei Interaktion mit gewissen Schaltflächen
kann so der Fall auftreten, dass Daten nicht mehr aktuell am Client vorliegen und neu
aus der Datenbank geladen werden müssen. Mit AJAX ist das Nachladen möglich,
ohne die komplette Seite neu zu laden. Dies stellt insofern einen Vorteil dar, dass die
Menge der gesendeten Daten minimiert und auch die Ladezeit, die für das Zeichnen
aller Objekte notwendig wäre, verringert wird oder ganz entfällt.
Erstmals wurde AJAX in einem Aufsatz von Jesse James Garett im Jahre 2005
erwähnt7
. Dies zeigt, dass die Entwicklung und der Einsatz des AJAX-Konzeptes erst
innerhalb der letzten Jahre stattfanden. Dementsprechend gibt es im World Wide Web
nur einen geringen, aber stetig wachsenden Teil von Internetpräsenzen, welche dieses
Konzept nutzen.
3.3. jQuery
„jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML
document traversal and manipulation, event handling, animation, and Ajax much
simpler with an easy-to-use API that works across a multitude of browsers. With a
combination of versatility and extensibility, jQuery has changed the way that millions of
people write JavaScript.“8
Wie im Zitat eingangs erwähnt, stellt jQuery eine JavaScript-Bibliothek dar, was die
Modifizierung des Document Object Model (nachfolgend „DOM“ genannt) vereinfacht
und zusätzlich auch das zuvor erwähnte Konzept AJAX zur Verfügung stellt. Das DOM
beschreibt den Baum, welcher sich aus den Elementen eines HTML-Dokumentes
zusammensetzt. jQuery ermöglicht es, auf Knoten des DOM zuzugreifen und diese mit
verschiedensten Funktionalitäten zu modifizieren, neu hinzuzufügen oder zu löschen.
6
Vgl. http://www.w3schools.com/html/html5_canvas.asp.
7
Vgl. Carl, Praxiswissen AJAX, S. 2.
8
Vgl. http://jquery.com/.

- 8 -
jQuery wird zwar erst seit dem Jahr 2006 angeboten, es wird jedoch zum Zeitpunkt
Dezember 2013 schon auf mehr als jeder zweiten Internetpräsenz weltweit genutzt.9
Die große Verbreitung wird dabei von der Tatsache unterstützt, dass jQuery im
Gegensatz zu manch anderen JavaScript-Bibliotheken kostenfrei – auch für
kommerzielle Projekte – zur Verwendung freigegeben ist.
3.4. Extensible Markup Language (XML)
„Extensible Markup Language“ ist, genau wie HTML, eine Auszeichnungssprache, um
Inhalte strukturell zu untergliedern. Strukturell unterscheidet sie sich von HTML in
einigen Merkmalen, auf die an dieser Stelle jedoch nicht eingegangen wird. XML stellt
eine Methode zur Verfügung, um Daten unabhängig in einem Text (beziehungsweise
einer Textdatei) zu speichern.
Da im späteren Teil der Arbeit (Kapitel 4.1.4.) erläutert wird, welches Ausgabeformat
für die API genutzt werden soll, gilt dieses Kapitel nur der Vollständigkeit, so dass der
Leser die Grundlagen vermittelt bekommt. Hierbei wird nicht weiter auf Vor- und
Nachteile eingegangen.
3.5. JavaScript Object Notation (JSON)
„JavaScript Object Notation“ stellt ein Datenformat dar, welches die Möglichkeit bietet,
Inhalte verschiedenster Datentypen zu serialisieren und kompakt zu speichern. Von
Vorteil ist die sowohl vom Mensch, als auch vom Computer lesbare Notation. JSON
gewann in den letzten Jahren immer mehr an Bedeutung und ist neben XML die
meistgenutzte Art der Speicherung von serialisierten Daten im Internet.10
Der Vorteil
von JSON ist, dass es unabhängig von der Programmiersprache ist und somit in fast
jeder gängigen Sprache ein Parser existiert. Zudem geht das parsen und Umwandeln
in ein Objekt wesentlich schneller, als dies bei XML der Fall ist. In Kapitel 4.1.4. wird
erläutert und entschieden, welches Ausgabeformat für die API gewählt wurde, weshalb
hierbei auch nicht weiter auf Vor- und Nachteile eingegangen wird.
9
Vgl. http://w3techs.com/technologies/overview/javascript_library/all.
10

- 9 -
3.6. OAUTH
OAUTH stellt ein Protokoll dar, mit dem Drittparteien einen Service über einen
gesicherten Zugang nutzen können. Dabei existieren folgende Entitäten, welche
innerhalb der Spezifikation von OAUTH als Rollen bezeichnet werden11
:
Client: Dieser will den Zugriff auf die geschützten Daten erhalten.
Resource Owner: Ihm gehören die geschützten Daten.
Resource Server: Dieser fungiert als Anbieter der Ressourcen.
Des Weiteren existiert ein Autorisierungsserver, welcher jedoch in den meisten Fällen
auf der Infrastruktur des Resource Server zu finden ist. Er dient der Autorisierung des
Clients, welcher auf die Daten zugreifen möchte. Wurde ein Client autorisiert, so erhält
er einen Access Token.12
Durch den Erhalt ist es dem Client möglich, auf die für ihn
freigegebenen Ressourcen zuzugreifen.
Da eine komplette Erläuterung des Protokolls den Rahmen dieser Arbeit überschreiten
würde und auch kaum weitere Aspekte des Protokolls implementiert werden sollen, soll
diese kurze Einführung ausreichend sein.
3.7. Hypertext Transport Protocoll (http)
3.7.1. Allgemeines
Das „Hypertext Transport Protocoll“ ist ein Protokoll zur Übertragung von Daten in
einem Netzwerk. Die hauptsächliche Verwendung findet HTTP dabei im World Wide
Web, um angefragte Seiten einer Internetpräsenz auszuliefern. HTTP wurde
zusammen mit den Konzepten URL und HTML ab 1989 im CERN in der Schweiz
entwickelt.13
Diese drei Konzepte stellen dabei die Grundlagen des World Wide Web
dar, die für eine Datei und deren Inhalt den Pfad zur Adresse der Datei und die Art der
Übertragung der Datei stehen. Dies entspricht im Wesentlichen auch der Bereitstellung
von Dateien auf allen anderen Arten von Computersystemen.
11
Vgl. Hardt, OAuth 2.0, S. 5.
12
Vgl. Hardt, OAuth 2.0, S. 10.
13
Vgl. Joos, PC-Netzwerke, S. 23.

- 10 -
Wichtig ist, dass das Protokoll als zustandslos gilt. Das bedeutet, dass es zu einer
Anfrage auch nur ein Resultat gibt, welches ausgeliefert wird. Technologien wie
Sessions oder Cookies werden demnach nicht genutzt.
Eine Anfrage per http besteht aus zwei Teilen:
1. dem Header (zu Deutsch: dem Kopf), welcher Meta-Informationen enthält und
2. dem Body (zu Deutsch: dem Körper), welcher ausschließlich Nutzdaten enthält.
Sowohl vom Client (also dem Browser), als auch vom Server wird eine Nachricht
gesendet, welche sich immer aus den zuvor genannten Teilen zusammensetzt. Man
spricht dabei von einer Anfrage und einem darauf folgendem Resultat.
3.7.2. http-Methoden
http bietet verschiedene Methoden an, um Elemente am angefragten Ziel zu
manipulieren.
Die zwei wichtigsten Methoden sind dabei:
1. GET: Dies ist die wohl üblichste Methode, weil sie automatisch ausgeführt wird,
sobald man die Adresse einer Internetpräsenz in die URL-Zeile eines Browsers
eingibt. Theoretisch ist es auch möglich, mit GET Dateien und Informationen
zum Server zu übertragen. Die Spezifikation der Methode sieht allerdings vor,
dass GET dazu genutzt werden soll, Dateien und Informationen abzurufen.
2. POST: Diese Methode dient im Allgemeinen dazu, Informationen oder Dateien
an einen Server zu übertragen. Zuvor am Server eventuell nicht existente
Informationen werden geliefert und nachfolgend weiter verarbeitet. POST dient
der Bearbeitung von bestehenden Informationen, insofern diese vorhanden
sind. Ebenfalls ist es möglich, eine Nachricht ohne Nutzdaten zu senden, was
im Grunde der Methode GET entspricht, da somit nur die referenzierten
Informationen abgerufen werden.
Außerdem existiert eine Menge weiterer Methoden, welche jedoch an dieser Stelle
nicht von Belang sind, um einen Grundüberblick über das Konzept von http zu
bekommen.

- 11 -
3.8. Hypertext Transport Protocoll Secure (https)
Eigentlich sind an dieser Stelle die Begriffe SSL beziehungsweise TLS zu nennen. Als
SSL entwickelt und ab einer späteren Version zu TLS (Transport Layer Security)
umbenannt, stellt dies ein Konzept dar, welches oberhalb des TCP Protokolls
angeordnet sein soll. Demnach wird also vor der eigentlichen Übertragung der Daten
noch ein Sicherheitsalgorithmus durchlaufen.14
Der Sinn hinter der Einführung des Protokolls ist, die zu versendenden Daten zu
verschlüsseln. Das Protokoll http versendet Parameter und URLS als Klartext, wodurch
es einem potentiellen Angreifer leicht gemacht wird, kritische Daten auszulesen. Hier
wird die Notwendigkeit der Nutzung von https ersichtlich.
Der hauptsächliche Bestandteil des Protokolls ist der sogenannte SSL Handshake,
welcher einen Schlüsselaustausch zwischen dem Server und dem Client ermöglicht.
Folglich können Nachrichten vor dem Senden verschlüsselt und nach dem Empfangen
wieder entschlüsselt werden, da nur Server und Client den notwendigen Schlüssel
kennen.15
3.9. Model-View-Controller (MVC)
Zur Strukturierung des erstellten oder zu erstellenden Programmcodes ist es oft
sinnvoll, gewisse Entwurfsmuster zu nutzen, um die Wartbarkeit und
Nachvollziehbarkeit des Codes zu erhöhen.
MVC steht für „Model-View-Controller“ und ist ein solches Entwurfsmuster. Die
Grundidee dahinter ist, die Geschäftslogik, die Abfragen nach Nutzdaten und die
Präsentation dieser zu trennen. In den meisten Fällen gilt es dabei, objektorientiert zu
programmieren, weshalb jeder Teilaspekt eine oder mehrere Klassen enthält.
In späteren Kapiteln, in denen die Implementierung erklärt wird, wird diese Aufteilung
der verschiedenen Aspekte am Beispiel der erstellten API erläutert.
14
Schwenk, Sicherheit und Kryptographie im Internet, S. 93.
15
Schwenk, Sicherheit und Kryptographie im Internet, S. 95-97.

- 12 -
3.10. PROPEL ORM
PROPEL ORM ist ein objektrelationales Datenbankframework. Für das eigene
Datenbankschema muss für die Benutzung von PROPEL ein Schema in XML-Form
vorliegen. Das Framework erstellt Klassendefinitionen, so dass dem Entwickler jedes
Ergebnis einer Datenbankabfrage immer als Objekt vorliegt. Dies hat den Vorteil, dass
der Zugriff auf die Attribute eines Objektes in gewisser Weise standardisiert ist.
Beispiel:
Eine Tabelle hat die Spalten „id“ und „name“. Der Entwickler stellt nun eine Anfrage an
die Datenbank und erhält sein Objekt, welches alle Inhalte der Zeile enthält, nach
welcher er in der Abfrage selektiert hat. Um auf die Attribute zuzugreifen, stellt
PROPEL nun, da es die Spaltennamen kennt, die Methoden getId() und getName() zur
Verfügung.
Nachteilig an PROPEL ist, dass der Entwickler kritischer mit der Erstellung von
Datenbankabfragen umgehen muss, weil sonst eine Menge Overhead erzeugt wird.
Overhead entspricht den übertragenen Daten, die nicht zu den Nutzdaten gehören.
Am aktuellen Beispiel:
Der Entwickler will nur den Wert in der Spalte „name“ ausgeben, selektiert jedoch
allgemein die ganze Zeile. Somit wird von der Datenbank auch das Attribut „id“
übergeben und am Server wird ein Objekt erzeugt. Somit dauert die Auslieferung der
Daten länger, als notwendig und auch das Objekt ist größer, als notwendig.
Bei sorgfältiger Programmierung bietet PROPEL jedoch einen sehr guten Arbeitsfluss,
besonders, wenn eine Anwendung sich am Konzept der objektorientierten
Programmierung orientiert.
3.11. Architektur und Entwicklungsrichtlinien der Earthfaves AG
3.11.1. Architektur
Für die Weiterentwicklung des Service der Internetpräsenz www.earthfaves.com gibt
es einige Entwicklungsrichtlinien, die an dieser Stelle kurz erklärt werden.
Neben der live-Domain www.earthfaves.com existieren noch zwei weitere Domains,
wobei eine nur eine Subdomain der live-Domain ist und den Bezeichner

- 13 -
stage99.earthfaves.com trägt. Die letzte Domain ist www.earthfaves.biz, welche als
Bereich für die Entwicklung von Prototypen genutzt wird. Jedem Entwickler wird dabei
ein eigener Bereich zugewiesen. Für den kompletten Quellcode existiert ein SVN-
Repository. Ein solches Repository ist für die Versionierung und Sicherung des
Quellcodes verantwortlich. Zusätzlich ist möglich, dass mehrere Entwickler gleichzeitig
an einer Datei arbeiten und dennoch kein programmierter Code verloren geht. Jeder
Entwickler erstellt sich eine lokale Kopie des kompletten Quellcodes und kann diesen
bearbeiten. Will man den erstellten Code testen, so lädt man ihn per FTP-Protokoll in
das jeweilige Verzeichnis auf dem Server hoch. Somit können die programmierten
Inhalte auf www.earthfaves.biz getestet und, falls nötig, nochmals bearbeitet werden.
Ist ein Prototyp fertig, so wird er im Entwicklerbereich auf Fehler getestet. Besteht er
den Test, so wird er auf den Testbereich stage99.earthfaves.com „geswitcht“. Dort wird
er nochmals von mehreren Entwicklern auf Fehler überprüft. Wird der Prototyp auch
hierbei fehlerfrei getestet, so wird er letztendlich auf die live-Domain übertragen, so
dass die Änderungen öffentlich werden und allen Benutzern von www.earthfaves.com
zur Verfügung stehen. Im Regelfall ist es jedoch selten so, dass einzelne Features auf
den Test- oder live-Bereich übertragen werden. In den meisten Fällen wird gleich ein
ganzes Paket an Änderungen übernommen und dieses gesammelt getestet.
Die Internetpräsenz wird in den Skriptsprachen PHP und JavaScript programmiert.
Dabei kommen Konzepte wie AJAX oder auch das Framework PROPEL zum Einsatz.
3.11.2. Datenbanken
Es existieren zwei verschiedene Datenbanken für die Entwicklung der Internetpräsenz
www.earthfaves.com. Eine steht dabei für den live-Bereich, welcher unter
www.earthfaves.com zu erreichen ist, zur Verfügung. Außerdem wird sie noch vom
Testbereich genutzt. Der Entwicklerbereich nutzt eine eigene Datenbank. Dies
geschieht aus dem Grund, dass bei der Entwicklung von Prototypen auch
Programmierfehler auftreten können. Durch das Testen mit einer eigenen Datenbank
ist so jedoch nicht der Inhalt der live-Datenbank gefährdet.

- 14 -
3.11.3. Framework
Für die Erstellung neuer Inhalte der Seite gilt es, den Code in verschiedenen Klassen
und Dateien strukturiert abzulegen, so dass bei der Wartung und Fehlerkorrektur
nachvollziehbar ist, an welcher Stelle man suchen muss.
Es existieren Klassen nach dem Namensschema „UIModules[…].php“, welche für das
Erzeugen von Bildschirminhalten in Form von HTML-Strukturen zuständig sind. Die
Funktionen zur Erzeugung werden als Methoden der gleichnamigen Klasse als statisch
deklariert. In der jeweiligen Datei, in der die Funktion benutzt werden soll, wird nun die
Methode der Klasse statisch aufgerufen, wodurch kein dauerhaftes Objekt erzeugt
werden muss.
Weiterhin existieren Klassen nach dem Namensschema „UIProvider[…].php“, welche
für die Datenbankzugriffe zuständig sind. Diese werden in gleicher Weise wie die zuvor
erwähnten Klassen genutzt.
Die eigentlich vom Server aufgerufene Datei verarbeitet gesendete Parameter und ruft
danach die entsprechende Funktion auf, welche die Bildschirminhalte erzeugen soll.
Innerhalb dieser Funktion wird dann gegebenenfalls noch eine Methode der Klasse für
Datenbankaufrufe verwendet und diese anschließend weiterverarbeitet. Letztendlich
gibt die Funktion einen String zurück und dieser wird in der Ursprungsdatei vom Server
an den Client zurückgegeben.
In vielen Fällen kommt noch AJAX zum Einsatz, wobei die eben erwähnte Datei dann
am Server aufgerufen wird.
Hinweis: Es ist zu erwähnen, dass auch für die Entwicklung der API nicht direkt der
live-Bereich genutzt wurde, sondern zuerst auf dem Entwicklerbereich. Deshalb lauten
später erwähnte URLs auch api.earthfaves.biz.

- 15 -
4. Anforderungsanalyse und Design
4.1. Anforderungsanalyse
4.1.1. Möglichkeiten und Nutzen einer API
Es stellt sich zu allererst die Frage: Wofür ist eine API in diesem Umfeld nützlich?
Schaut man sich die rasante Entwicklung im Bereich der APIs an, welche schon in der
Motivation dieser Arbeit erwähnt wurde, so ist zu erkennen, dass inzwischen fast jeder
größere Anbieter von Internetdiensten eine API anbietet. Stellt man sich nun die Frage,
inwiefern eine API nützlich für ein Unternehmen ist, so lässt sich die Frage sehr
umfassend beantworten. Da dies auch im Falle der Earthfaves AG von Bedeutung ist,
wird die Frage an dieser Stelle beantwortet.
Zum einen gilt natürlich, dass man den angebotenen Service zum Teil oder auch ganz,
auch außerhalb der Domaingrenze, nutzen kann. Dies bietet den Vorteil, dass man
nicht an die Website des Anbieters gebunden ist. Daraus resultierend entsteht so in
gewissem Maß die Möglichkeit auf der API aufbauend eine eigene Anwendung zu
entwickeln. Beispiele hierfür sind Services wie HootSuite, welche die API eines
Anbieters nutzen, um darauf aufbauend eine unabhängige Client-Software
anzubieten.16
Von Vorteil daran ist, dass dem Endkunden verschiedene Möglichkeiten
gegeben sind, einen Service zu nutzen. Am Beispiel des sozialen Netzwerks Twitter
lässt sich erkennen, dass es viele verschiedene Services gibt, welche ihr Angebot über
die Twitter-API zur Verfügung stellen.17
Dabei ist sogar zu sehen, dass der Service
zum Teil weitgehender über externe Zugriffe genutzt wird, als auf der Internetpräsenz
selbst. Daraus resultierend kann man schlussfolgern, dass das Anbieten einer solchen
API von nicht unerheblicher Wichtigkeit sein kann.
Weiterhin bietet eine eigene API dem Anbieter die Möglichkeit, die eigene Marke und
auch Inhalte des eigenen Service so schneller zu verbreiten. Stellt eine API eine
besonders leicht zu handhabende Schnittstelle dar – sprich: ist die Qualität der
angebotenen Software gut –, so lässt sich diese auch dementsprechend einfach in
externe Services einbinden. Daraus resultierend lässt sich erklären, weshalb ein gutes
API Design wichtig ist. Zudem liefert eine gute API auch eine größere
16
Vgl. https://hootsuite.com/.
17
Vgl. http://maximizesocialbusiness.com/top-25-twitter-clients-top-50-social-media-influencers-9349/.

- 16 -
Benutzerreichweite im World Wide Web. Stellt sich eine API als gut nutzbar heraus, so
erfreut sich diese mit hoher Wahrscheinlichkeit einer großen Beliebtheit unter den
Anwendern und setzt sich dementsprechend möglicherweise auch genau deshalb
gegen Konkurrenzprodukte durch. Eine gute API kann demzufolge auch einen nicht
optimalen Service dahingehend unterstützen, als dass der Anbieter durch die hohe
Nutzung viel mehr Rückmeldung bekommt.
Ebenfalls ist zu betrachten, inwiefern eine API zur Monetarisierung eines Service
beitragen kann. Durch eben angesprochene Vorteile ist es natürlich auch möglich, den
Endpreis für den Service zu erhöhen, da dem Benutzer der API somit ein mächtiges,
einfach zu handhabendes Werkzeug zur Verfügung gestellt wird.
Als letzter hier zu betrachtender Punkt steht die Innovation, die von einer API
ausgehen kann. Weil die Nutzung von APIs im Bereich des World Wide Web erst in
den letzten Jahren richtig ins Laufen kam, gibt es wohl kaum eine API, welche
fehlerfrei und als das Non-Plus-Ultra anzusehen ist. Einer Umfrage unter 100
Entwicklern zufolge hat beispielsweise Facebook die schlechteste API, da sie zum Teil
unzureichend dokumentiert und des Weiteren teilweise schwer zu handhaben ist.18
Deshalb stehen wohl noch alle Möglichkeiten offen, eine gute API zu entwickeln, ohne,
dass man sich strikt an alle Vorgaben hält und dementsprechend sich nicht im Raum
innovativer, neuer Technologien und Konzepte bewegt. Sicher gibt es gewissermaßen
auch jetzt schon best-practice-Ansätze, jedoch zeigt die zuvor erwähnte Umfrage, dass
auch diese noch verbesserungswürdig sein können.
Zusammenfassend lässt sich also sagen, dass eine gute API ein Unternehmen
durchaus in weiten Teilen seines Geschäftsmodells voranbringen kann.
Dementsprechend wichtig ist allerdings auch die Umsetzung, beziehungsweise das
Design der API, da das nachträgliche Ändern einiger Komponenten oder der ganzen
API zwangsläufig auch das Benutzerverhalten tangiert.19
Betrachtet man nun ein konkretes aber fiktives Beispiel, so wäre beispielsweise das
Anzeigen von Empfehlerkommentaren auf der Internetpräsenz eines Geschäftskunden
zu nennen. Der Geschäftskunde erstellt sich in einer Programmiersprache seiner Wahl
Programmcode, welche für die Anzeige der Kommentare verantwortlich sein soll.
Danach muss er nur noch per URL-Anfrage alle notwendigen Daten auslesen. Gewinnt
er auf der Internetpräsenz www.earthfaves.com einen neuen Empfehler, so wird dieser
18
Vgl. http://t3n.de/news/entwickler-umfrage-facebook-hat-grausligste-api-325571/.
19
Vgl. Bloch, API Design.

- 17 -
automatisch auch mit auf seine eigene Internetpräsenz übernommen, da die API
immer aktuelle Daten und Informationen liefert.
4.1.2. Anforderungen an die API
Auf die Frage, was eine API leisten soll, beziehungsweise welche Funktionalitäten sie
zur Verfügung stellen soll, lässt sich nicht allgemein antworten. Daher wird die Frage
hier spezifisch für die zu erstellende API der Earthfaves AG beantwortet. Ziel war,
einem Geschäftskunden der Earthfaves AG die Möglichkeit zu bieten, seine Daten,
welche er über den Service auf der Internetpräsenz www.earthfaves.com auch erhalten
kann, zu beziehen. Dabei sollte jedoch vorerst nur ein Bruchteil der insgesamt
vorhandenen Daten abrufbar sein, da es zu umfangreich wäre, die gesamte
Funktionalität in einer API abzubilden.
Konkret sollte dem Geschäftskunden die Möglichkeit gegeben werden, Daten zu
seinen Empfehlern, seinen ehemaligen Empfehlern und zu Personen, welche das
Unternehmen noch nicht empfehlen, zu erhalten. Zu Letzterem muss man erwähnen,
dass das „Noch nicht empfehlen“ explizit vom Benutzer ausgewählt werden muss. Es
besteht so die Möglichkeit, einem Unternehmen Kritik und Vorschläge zu unterbreiten,
so dass man das Unternehmen bei einer Besserung gegebenenfalls empfehlen würde.
Des Weiteren soll die API Gelegenheit bieten, Daten zu einzelnen Empfehlern
abzufragen. Zuletzt soll man noch Daten zu einem earthfave abfragen können.
Zusätzlich zu den oben genannten Fällen, soll der Geschäftskunde über die API einen
Access Token erhalten. Bei erstmaliger Aktivierung und Zustimmung zur Nutzung der
API erhält er einen Public Key, einen Private Key und einen Access Token. Die
Anforderung an den Access Token ist, dass dieser nur für einen gewissen Zeitraum
gültig ist. Ist dieser abgelaufen, soll es dem Geschäftskunden möglich sein, über die
API einen neuen Access Token zu beziehen, so dass er nicht darauf angewiesen ist,
die Internetpräsenz www.earthfaves.com dafür zu nutzen. Ebenfalls ist das ständige
Abrufen des aktuell gültigen Access Token über den Public Key und den Private Key
möglich.

- 18 -
4.1.3. Welche Informationen soll die API liefern
Die Anforderung an die API war, dem Geschäftskunden Gelegenheit zu bieten,
möglichst viele Daten, welche er auch über den Service auf der Internetpräsenz
www.earthfaves.com erhalten kann, zu beziehen. Dabei galt es, zuerst nur die am
höchsten priorisierten Informationen mit der API auszugeben. Dies entspricht in etwa
Folgendem:
 Informationen zu Personen, die einen earthfave empfehlen
o Eingabe:
 earthfave id
o Ausgabe:
 Allgemeine Informationen, wie Name und Wohnort
 Informationen zur Empfehlung, wie das Datum und der
Kommentar
 Tiefergehende Informationen über das Netzwerk des
Empfehlers, wie die Anzahl Freunde, Freundesfreunde
und so weiter
 Informationen zu Personen, die einen earthfave nicht mehr empfehlen
o Eingabe:
 earthfave id
o Ausgabe:
 Informationen zur ehemaligen Empfehlung, wie das
Datum und der Kommentar
Empfehlers, wie die Anzahl der Freunde,
Freundesfreunde und so weiter
 Informationen zu Personen, die einen earthfave explizit noch nicht
empfehlen
o Eingabe:
 earthfave id
o Ausgabe:
 Informationen zur ehemaligen Empfehlung, wie das
Datum und der Kommentar

- 19 -
Empfehlers, wie die Anzahl der Freunde,
Freundesfreunde und so weiter
Zu allen drei Fällen soll jeweils auch die Gesamtzahl der Empfehler, ehemaligen
Empfehler oder Personen, die noch nicht empfehlen, ausgegeben werden. Die drei
genannten Fälle stellen eine erweiterte Unterscheidung der Benutzer von
www.earthfaves.com dar. Dies bezieht sich allerdings nur auf die Beziehung zu einem
earthfave und dem dazugehörigen Geschäftskunden.
Weitergehend wurde folgender Fall priorisiert:
 Informationen zu einem Benutzer der Internetpräsenz www.earthfaves.com
o Eingabe:
 Benutzer id
o Ausgabe:
 Eine Liste seiner earthfaves
 Die er mit „war schon dort“ markiert hat
 Die er mit „will dahin“ markiert hat
 Informationen zu verbunden sozialen Netzwerken
Zu jedem earthfave sollen kurz die wichtigsten Informationen ausgegeben werden.
Diese sind die id, der Name, Längen- und Breitengrad und spezifische Informationen
zum Empfehler, wie der Kommentar.
Zuletzt war noch ein Fall zu beachten:
 Informationen zu einem earthfave:
o Eingabe:
 earthfave id
o Ausgabe:
 Anzahl der Empfehler
 Allgemeine Daten, wie Name, Längen- und Breitengrad,
Kategorien und Ähnliches
Die drei zuerst genannten Fälle beziehen sich alle nur auf die Ausgabe der
Informationen zu einem earthfave. Das Konzept der Internetpräsenz
www.earthfaves.com sieht vor, dass einem Geschäftskunden allerdings auch mehrere
earthfaves zugeordnet sein können, wenn das Unternehmen z.B. eine größere Kette
ist. Dafür sollte in der API sowohl die Möglichkeit gegeben sein, Empfehler und

- 20 -
Ähnliches zu einem earthfave abzufragen, als auch die Möglichkeit, sich die Empfehler
aller earthfaves, die dem eigenen Unternehmen zugeordnet sind, geordnet ausgeben
zu lassen. Problematisch daran ist, dass das Konzept noch nicht vollständig auf der
Internetpräsenz umgesetzt ist. Demzufolge wurde dieser Teil der API auch erst einmal
außen vorgelassen. Da die API so programmiert und designt werden soll, dass eine
Erweiterung im Nachhinein kein großes Problem darstellt, ist das Auslassen gewisser
Teile an dieser Stelle auch kein Problem.
Zusätzlich soll der Benutzer noch seinen aktiven Access Token abfragen können,
welcher somit auch der einzige Bestandteil der Rückgabe sein soll.
4.1.4. Festlegung des Ausgabeformats
Zur Entscheidungsfindung, welches Ausgabeformat die API liefern soll, standen zwei
Optionen zur Verfügung. Dies sind zum einen XML und zum anderen JSON. Es galt
unter anderem abzuwägen, welches Format das sinnvollere ist. Die Sinnhaftigkeit
eines Ausgabeformates lässt sich in den meisten Fällen nur unter folgenden
Gesichtspunkten betrachten:
 Verbreitung/Popularität
 Größe der Ausgabe im jeweiligen Format
 Geschwindigkeit beim Parsen
 Unterstützung in verschiedenen Programmiersprachen
Wie schon erwähnt, sind JSON und XML nahezu gleich weit verbreitet, wobei XML
wohl noch etwas mehr genutzt wird, als JSON.20
Allerdings ist auch der Trend der
ansteigenden Nutzung von JSON nicht zu vernachlässigen.21
Außerdem kann man die Größe der Ausgabe in XML und JSON vergleichen. Dazu
existiert eine Vielzahl an Tests, welche nachzuweisen versuchen, welches
Ausgabeformat „platzsparender“ ist.22
Allerdings ist eine Aussage über die Größe der
Formate auch immer abhängig vom zu testenden Fall der Ausgabe. Deshalb ist an
dieser Stelle keine konkrete Entscheidung zu finden.
20
21
Vgl. http://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-
verbosity.
22
Vgl. http://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-
verbosity.

- 21 -
Die Geschwindigkeit beim Parsen der serialisierten Objekte lässt sich nicht so leicht
vergleichen, da es im weiteren Verlauf darauf ankommt, ob ein Browser einen nativen
JSON Parser enthält. Ist dieser enthalten, so ist auch das JSON als nativ anzusehen.
Somit geht das Parsen von JSON standardmäßig schneller als das Parsen von XML,
da JSON prinzipiell gültige JavaScript-Syntax ist und XML eine Menge Overhead
enthält.
Die Unterstützung von JSON und XML ist in praktisch allen gängigen
Programmiersprachen gegeben, was bedeutet, dass dieses Kriterium für die
Entscheidungsfindung nicht von Relevanz ist.
Zusammenfassend lässt sich also sagen, dass, insofern es auf schnelle und einfache
Verarbeitbarkeit ankommt, JSON zu wählen ist. Auch der steigende Trend zur Nutzung
von JSON spielt hierbei eine große Rolle, weil man sich bei der Entwicklung auch an
aktuellen Trends orientieren sollte. Letztendlich wäre es sinnvoll, beide Formate
anzubieten. Da es hierbei aber um die Suche nach einem bevorzugten Format geht,
welches zuerst zu implementieren sein sollte, fiel die Wahl auf JSON.
4.1.5. Weitere Anforderungen
4.1.5.1. Erweiterung des Datenbankmodells
Anforderungen an die Datenbank bestehen insofern, als dass neue Tabellen angelegt
werden müssen. Diese müssen speichern, welcher Benutzer sich für die Benutzung
der API eingetragen hat und welche verschiedenen Aufgaben die API anbieten soll.
Weiterhin muss gespeichert werden, wie oft ein Nutzer auf die API täglich zugreifen
darf. Schließlich muss es eine Tabelle zum Speichern aller Anfragen an die API geben.
Alle eben genannten Datenbanken mussten neu erstellt werden.
4.1.5.2. Entwicklung einer Administrationsoberfläche
Zur Steuerung und Überwachung der API sollte eine Administrationsoberfläche erstellt
werden, welche den Zugang zu einzelnen Teilen der API regelt. Weiterhin muss

- 22 -
ersichtlich sein, welche Benutzer sich momentan für die Nutzung der API registriert
haben. Außerdem muss eine Übersicht über die letzten Zugriffe erstellt werden.
4.1.5.3. Erweiterung der Internetpräsenz für Geschäftskunden
Um sich für die Nutzung der API zu registrieren, soll es dem Geschäftskunden möglich
sein, sich in einem Unterpunkt des Menüs, welches ausschließlich den
Geschäftskunden zugänglich ist, für die Nutzung anzumelden. Durch das Anmelden,
das in Form des Setzens eines Häkchens erfolgt, erhält der Benutzer einen Private
Key, einen Public Key und einen Access Token. Public Key und Private Key sind
hierbei als Zeichenketten zu verstehen, die einen Geschäftskunden identifizieren.
Dabei wird kein Bezug auf den tatsächlichen Benutzernamen oder das Passwort
genommen, da Public Key und Private Key nur für die API genutzt werden sollen.
Ebenfalls sind Public Key und Private Key nicht zum Verschlüsseln und Entschlüsseln
von Informationen zu benutzen. Sie dienen allein der Identifizierung beim Anfordern
eines neuen Access Token. Die dementsprechenden Daten müssen somit in der
Datenbank angelegt werden. Meldet sich der Benutzer wieder ab, so sollen die Daten
aus der Datenbank entfernt werden, damit keine obsoleten Daten in der Datenbank
vorliegen.
4.2. Design
4.2.1. Anwendung von MVC und objektorientierter Programmierung
Für die Erstellung der API wurde das Entwurfsmuster MVC gewählt. Dies geschah aus
den Gründen, dass durch eine klare Trennung des Codes in verschiedene Bereiche die
Nachvollziehbarkeit des Codes erhöht wird. Da mit großer Wahrscheinlichkeit auch
weitere Entwickler die API erweitern werden, ist die Nachvollziehbarkeit ein wichtiger
Grund für die Wahl eines solchen Entwurfsmusters. Geteilt ist der Programmcode
somit in zwei Controller-Klassen, eine Model-Klasse und eine View-Klasse.
Bei der Umsetzung des MVC-Entwurfsmusters ist es prinzipiell fast unmöglich, dieses
nicht objektorientiert zu realisieren, da es darauf ausgelegt ist. Deshalb wurde an

- 23 -
dieser Stelle auch der Weg der objektorientierten Programmierung gewählt. Es
existieren folglich zwei Controller-Klassen, eine Model-Klasse und eine View Klasse.
Durch das Erstellen und Benutzen von Klassen bei der Programmierung einer API wird
ebenfalls die Nachvollziehbarkeit erhöht. Durch die klare Trennung der Teilbereiche
sollte man als Entwickler sofort wissen, an welcher Stelle Neuimplementierungen
einzufügen sind. Da MVC nicht einhundertprozentig vorschreibt, welche Art von Code
an welcher Komponente anzusiedeln ist, wird nachfolgend noch erläutert, für welche
Aufgaben die einzelnen Klassen verantwortlich sind.
Klar bei der Definition von MVC ist, dass die Model-Klasse die Informationen der
Anwendung enthält und die View-Klasse die Ausgabe der Daten strukturieren und
steuern soll. An welcher Stelle jedoch die Logik der Anwendung stehen soll ist nicht
konkret festgelegt. Dabei ist es möglich, die gesamte Logik in der Controller-Klasse zu
schreiben oder einen Teil davon in die Model-Klasse auszulagern.
4.2.2. Ein Controller-Objekt für die Logik
Der Controller ist für die Aufnahme der in der URL übergebenen Parameter zuständig.
Diese werden im Konstruktor der Klasse einem Objekt zugewiesen, welches beim
Aufruf immer erzeugt wird. Somit ist der Controller weiterhin auch für sämtliche Logik
und Verarbeitung aller Daten zuständig. Hierbei werden auch zeitweise Strukturen
erzeugt, die die Struktur der Ausgabe beeinflussen. Ebenfalls ist der Controller für die
Validierung der Daten, welche vom Benutzer der API gesendet werden, zuständig. Das
Model- und das View-Objekt sind Aggregat-Objekte des Controller-Objektes.
4.2.3. Ein Model-Objekt für die Datenbank
Das Model-Objekt ist rein für die Zugriffe auf die Datenbank zuständig. Es baut im
Konstruktor eine Verbindung zur Datenbank auf. Für Zugriffe auf die Datenbank wird
die PHP-Erweiterung mysqli genutzt. Diese stellt die Erweiterung zu den mysql-
Funktionen von PHP dar und ist ergänzt um die Möglichkeit, objektorientiert zu
arbeiten. Die Funktionen der Model-Klasse geben ein mysqli-Objekt zurück, welches
im Controller weiter verarbeitet wird. Auf eine Verarbeitung im Model-Objekt wurde
verzichtet, weshalb in den Methoden der Klasse nur der Zugriff auf die Datenbank
realisiert wird und das Resultat dem Controller zurückgeliefert wird.

- 24 -
4.2.4. Ein View-Objekt für die Ausgabe
Nach Abfrage aller Daten und der dementsprechenden Verarbeitung bleibt noch die
Aufgabe, die Daten strukturiert auszugeben. Dafür ist die View-Klasse
beziehungsweise das View-Objekt zuständig. Dem Objekt werden alle wichtigen
Strukturen und Daten übergeben, welche es zeitweise speichert. Ebenfalls ist das
View-Objekt für die Konvertierung in das jeweilige Ausgabeformat zuständig. Da für die
Implementierung im Rahmen dieser Arbeit nur das Format JSON zu wählen ist, wird
auch nur ein View-Objekt benötigt. Mit der Erweiterung auf die Möglichkeit, die Daten
per XML auszugeben, könnte einfach eine weitere Klasse hinzugefügt werden, welche
theoretisch in selber Weise wie die bestehende Klasse funktioniert. Jedoch sollte diese
dann die Ausgabe in XML beherrschen.
4.2.5. Ein Controller-Objekt für die Zeitmessung
Des Weiteren war es eine Anforderung, dass die Zugriffe auf die API in einer Tabelle
der bestehenden Datenbank abgespeichert werden können. Dafür sollte außer dem
Pfad, auf welchen zugegriffen wird, auch die Zeit abgespeichert werden, die benötigt
wird, um die fertige Ausgabe zu erzeugen. Um einen Timer zu starten
beziehungsweise zu stoppen, und die Laufzeit zurückzugeben, stellt dieses Objekt
Methoden zur Verfügung. Es stellt dabei ein separates Objekt dar und ist kein Teil des
Controller-Objektes, welches die Eingabe und die Logik verwaltet.
4.2.6. http-Methoden und URLs
Das Abfragen von Daten in der API soll über das Absenden einer URL möglich sein.
Wie schon zuvor erwähnt, existieren Methoden im Protokoll http, welche auch hierbei
Anwendung finden sollen. Hauptsächlich wird dies die Methode GET sein. Diese ist für
das Abfragen von Daten zuständig. In einem Fall, nämlich dem Anfordern eines neuen
Access Token, muss jedoch nicht GET, sondern POST genutzt werden, da an dieser
Stelle eine neue Ressource am Server erzeugt wird.
Die URLs sollen Aufschluss darüber geben, welche Daten abgefragt werden. Deshalb
ist es wichtig, aussagekräftige Namen zu wählen, welche die jeweilige Ressource
auszeichnen. Im Folgenden werden die URLs für alle Fälle der Ausgabe von Daten

- 25 -
aufgelistet und erläutert. Rot markiert sind dabei die Teile der URL, die dynamisch
eingetragen werden müssen.
 Daten zu den Empfehlern eines earthfaves:
http-Methode: GET
api.earthfaves.biz/business/oneeffaver/earthfave_id?access_token=access_tok
en
Feste Bestandteile sind die Hierarchieebenen „business“, welche suggeriert,
dass Daten für einen Geschäftskunden abgerufen werden sollen und
„oneeffaver“, welches an dieser Stelle für „one earthfave faver“ steht. Somit
sollen alle Empfehler zu einem speziellen earthfave ausgegeben werden.
Dieser earthfave muss zwangsläufig mit dem Geschäftskunden in Verbindung
stehen, sonst wird eine Fehlermeldung erzeugt. Daher ist es einem
Geschäftskunden nur möglich, die eigenen earthfaves auszugeben. Außerdem
wird eine id für einen earthfave erwartet, welche der id in der Datenbank
entspricht. Ein gültiger Access Token muss übergeben werden, da sonst die
Abfrage nicht möglich ist.
 Daten zu den ehemaligen Empfehlern eines earthfaves
http-Methode: GET
api.earthfaves.biz/business/oneefexfaver/earthfave_id?access_token=access_t
oken
Fest ist, wie zuvor auch, der Teil „business“ und zusätzlich der Teil
„oneefexfaver“. Dieser Teil steht hierbei für „one earthfave exfaver“, also für alle
ehemaligen Empfehler. Die Einschränkungen zur Zugehörigkeit des Earthfaves
zum Geschäftskunden sind dabei ebenso gültig wie im zuvor genannten Fall.
Dementsprechend wird auch hierbei wieder eine earthfave id erwartet. Auch
muss wieder ein Access Token übergeben werden.
 Daten zu Personen, die einen earthfave explizit noch nicht empfehlen
http-Methode: GET
api.earthfaves.biz/business/oneefnotfaver/earthfave_id?access_token=access_
token
Auch hierbei gelten zuvor getroffenen Aussagen. Hierbei steht „oneefnotfaver“
allerdings für „one earthfave notfaver“. Es sollen Informationen über alle
Personen ausgegeben werden, die explizit das Unternehmen oder den
earthfave noch nicht empfehlen. Ein Access Token wird an dieser Stelle
ebenfalls benötigt.
 Daten zu einem Benutzer
http-Methode: GET

- 26 -
api.earthfaves.biz/user/info/user_id?access_token=access_token
Hierbei werden Daten zu einem Benutzer ausgegeben, daher ist die erste
Hierarchieebene der URL „user“. Der zweite Teil „info“ gibt Aufschluss darüber,
dass allgemeine Informationen über den Benutzer ausgegeben werden sollen.
Es folgt eine Benutzer id und der notwendige Access Token.
 Daten zu einem earthfave
http-Methode: GET
api.earthfaves.biz/earthfave/info/earthfave_id?access_token=access_token
Ähnlich dem Fall des Abfragens von Benutzerdaten setzt sich die URL aus
„earthfave“ und „info“ zusammen, was bedeutet, dass Daten zu einem
earthfave ausgegeben werden sollen. Erwartet werden eine earthfave id und
ein gültiger Access Token.
 Den momentan gültigen Access Token abfragen
http-Methode: GET
api.earthfaves.biz/authenticate/business/?public_key=public_key&private_key=
private_key
Hat ein Geschäftskunde sich für die Nutzung der API registriert, so kann er über
diese URL seinen Access Token erhalten. Die URL setzt sich aus den Teilen
„authenticate“ und „business“ zusammen, was bedeutet, dass
Authentifizierungsdaten eines Geschäftskunden abgefragt werden sollen. Wird
die Methode GET gewählt, so können über die URL ein Public Key und ein
Private Key übermittelt werden, was den Benutzer am Authentifzierungsserver
authentifiziert.
 Einen neuen Access Token erhalten
http-Methode: POST
api.earthfaves.biz/authenticate/business/
Wird die Methode POST auf die gleiche URL wie zuvor angewendet, besteht
die Möglichkeit, einen neuen Access Token zu erzeugen. Dies ist notwendig,
wenn ein Access Token abgelaufen und nicht länger gültig ist. Dabei müssen
public_key und private_key als POST-Daten übermittelt werden, weshalb sie
nicht in der URL ersichtlich sind.
Die schon erwähnten Fälle, dass ein Geschäftskunde die Daten zu mehreren
Earthfaves abfragen kann, sind in dieser Übersicht nicht erwähnt, auch wenn
zumindest der Methodenaufruf schon in der API implementiert ist. Dafür wird eine
dementsprechende Fehlermeldung erzeugt. Dies wird im folgenden Kapitel erläutert.

- 27 -
4.2.7. Beschränkung des Zugriffs
Da die API nicht für jeden zugänglich sein soll, besteht als erste Absicherung der
erwähnte Access Token. Dieser stellt sicher, dass nur registrierte Nutzer auf die
Funktionalitäten zugreifen können. Ebenfalls wird über den Access Token festgestellt,
welcher Benutzer die Anfrage an die API sendet. Darüber kann ebenfalls sichergestellt
werden, dass ein Geschäftskunde auch wirklich nur Zugriff auf seine persönlichen
Daten hat. Dies schließt die Daten aller seiner Empfehler mit ein.
Da die API jedoch nicht ununterbrochen und kontinuierlich genutzt werden kann, sollen
weitere Sicherheitsmechanismen implementiert werden. Die Motivation für die
Implementierung dieser ist vor allem die Tatsache, dass sich das Geschäftsmodell der
Earthfaves AG für Geschäftskunden in drei Bereiche aufteilen lässt. Wie schon
erwähnt besteht die Möglichkeit, verschiedene Service-Pakete zu kaufen, wodurch
unterschiedliche Inhalte für Geschäftskunden freigeschaltet werden. Dies soll sich auch
in der möglichen Nutzung der API niederschlagen. Hat ein Kunde beispielsweise nur
das Bronze-Paket gekauft, so erhält er unter Umständen nicht Zugriff auf alle
implementierten Funktionalitäten der API. Auch die Anzahl der täglichen Zugriffe auf
die API sollen regulierbar sein, so dass es nicht möglich ist, den Server mit Anfragen
zu fluten. Da dies den Server verlangsamen kann, wird jedem Paket eine gewisse
Anzahl an Zugriffen pro Tag zugewiesen. Die momentan zu wählenden Zahlen sind
dabei jedoch nur als Test zu verstehen. Wie viele Zugriffe ein Kunde im Durchschnitt
wirklich braucht, lässt sich wohl nur durch Kundenmeinungen und das Erstellen von
Statistiken evaluieren.
Des Weiteren soll es nach Belieben möglich sein, einzelne Funktionen der API zu
sperren. Dies kann eine Reaktion auf bekannte Fehlfunktionalitäten sein. Ist der Fehler
behoben, so kann die Funktionalität wieder entsperrt werden. Ein vorletzter Punkt der
Sicherung des Zugriffs ist die Überprüfung, ob ein Geschäftskunde den Service auch
weiterhin bezahlt hat. Läuft die bezahlte Zeit des Service aus, so verwirkt der
Geschäftskunde auch die Möglichkeit zur Nutzung der API.
Zuletzt zu erwähnen ist die Tatsache, dass ein Access Token ein Ablaufdatum besitzt.
Dies stellt sicher, dass der Geschäftskunde seinen Zugang von Zeit zu Zeit neu
verifizieren muss. Mögliche Gefahren bestehen darin, dass ein einmalig angeforderter
Access Token firmenextern in Umlauf gerät und man damit außenstehenden die
Möglichkeit gibt, die API ebenfalls zu nutzen und somit persönliche Daten abzufragen.
Ein Access Token soll nur drei Monate gültig sein. Da die Möglichkeit besteht, durch
eine Anfrage an die API einen neuen Access Token zu erhalten, ist es dem

- 28 -
Geschäftskunden auch möglich, die Anforderung des neuen Access Tokens zu
automatisieren. Die API gibt eine Fehlermeldung zurück, insofern der Access Token
fehlerhaft oder nicht mehr gültig ist. Durch geschickte Implementierung kann
unproblematisch eine automatisierte Anfrage gesendet werden, welche einen neuen
Access Token anfordert.
4.2.8. Ausgabestruktur
Allgemein gliedert sich die Ausgabe in zwei Teile:
1. Den Status der Anfrage als Metadaten
2. Die Inhalte als Nutzdaten
Der Status soll dabei einen http-Statuscode enthalten, welcher im folgenden Kapitel
genauer erläutert wird. Weiterhin sollen die allgemeine Bezeichnung des Statuscodes
und eine detailliertere Beschreibung enthalten sein. Diese sollen dem Benutzer
Aufschluss darüber geben, ob die Anfrage erfolgreich war. War sie das nicht, so sollen
die Informationen dem Benutzer möglichst genau beschreiben, inwiefern die Anfrage
nicht bearbeitet werden konnte, beziehungsweise, worin der Fehler bestand.
Für die Nutzdaten ist kein festes Ausgabeformat definiert. Diese richten sich nach der
Funktionalität, von welcher Gebrauch gemacht wird. Auch ist die Größe der
auszugebenden Daten stark vom Nutzer abhängig. Ein Geschäftskunde mit 1000
Empfehlern wird vermutlich eine umfangreichere Ausgabe erwarten können als ein
anderer Kunde, der nur 100 Empfehler hat.
Bei der Strukturierung der Ausgabe wurden ausschließlich englischsprachige
Bezeichner für Eigenschaften und Objekte gewählt, weil eine mehrsprachige
Implementierung nicht zwingend notwendig sein sollte. Die Earthfaves AG sieht ihren
Einflussbereich nicht nur in Deutschland, was die Nutzung der API auch durch nicht
deutschsprachiger Programmierer wahrscheinlich macht. Deshalb ist die Konvention,
alles rein in englischer Sprache zu implementieren, die wohl sinnvollste Lösung.
Die folgende Abbildung zeigt die beispielhafte Ausgabe der Metadaten zum Aufruf der
Empfehler eines earthfaves.

- 29 -
Abbildung 1: Beispielhafte Ausgabe der Metadaten
Die Ausgabe der Nutzdaten ist in der nachfolgenden Abbildung dargestellt. Jedoch ist
sie nicht vollständig und soll nur beispielhaft sein.
Abbildung 2: Beispielhafte Ausgabe der Nutzdaten
4.2.9. Statuscodes
Um dem Benutzer das Erkennen und Beseitigen von Problemen so leicht wie möglich
zu machen wird bei jeder Anfrage an die API ein Statuscode zurückgegeben. Dieser
soll Aufschluss darüber geben, wie sich die Bearbeitung der Anfrage verhalten hat.
Die folgende Tabelle zeigt die möglichen http-Statuscodes und die dazugehörigen
Informationstexte. Dabei werden die originalen Statusmeldungen in englischer Sprache
aufgeführt. In der letzten Spalte wird eine deutsche Beschreibung der Fälle aufgezeigt,
in denen die Statusmeldungen auftreten können.

- 30 -
HTTP Status
Code
Erklärung Statusmeldung Anwendungsfall
200 Ok Your request was
successful and your
result will be returned
In allen Fällen,
wenn die Ausgabe
erfolgreich war.
201 Created Your new Access
Token have been
created and returned.
Das Anfordern
eines neuen
Access Tokens
war erfolgreich.
400 Bad Request Please check your
syntax.
Die URL enthält
fehlerhafte
Zeichen oder ein
syntaktischer
Fehler liegt vor.
401 Unauthorized This combination
private key and public
key is not valid
Private Key und
Public Key passen
nicht zusammen
oder einer der
beiden ist
ungültig.
401 Unauthorized Get a valid Access
Token.
Der Access Token
ist fehlerhaft.
401 Unauthorized Your Access Token
may not be valid any
more.
Der Access Token
ist nicht länger
gültig. Ein neuer
muss angefordert
werden.
403 Forbidden The User doesn't exist
or is not in relation
with your business.
Es werden Daten
zu einem
Benutzer
abgefragt, für
welche der
Geschäftskunde
nicht berechtigt
ist.
403 Forbidden Your business level is
not high enough
Der
Geschäftskunde
muss ein
höherwertigeres
Service-Paket
bezahlen.
403 Forbidden You need to pay
again for the business
service
Der
Geschäftskunde
hat nicht mehr für
den Service
bezahlt und ist
deshalb von der
Nutzung
ausgeschlossen.
403 Forbidden The earthfave doesn't
exist or is not in
relation with your
business
Es werden Daten
zu einem
earthfave
abgefragt, für
welche der

- 31 -
Geschäftskunde
nicht berechtigt
ist.
423 Locked The source is
currently locked.
Die Funktion
wurde gesperrt
und kann
momentan nicht
genutzt werden.
429 Too many requests You have sent to
many requests today.
Die Anzahl der
persönlichen
täglichen Zugriffe
wurde
überschritten.
501 Not implemented This function exists
but is not
implemented yet.
Die angeforderte
Ressource kann
aufgrund der
fehlenden
Implementierung
nicht ausgegeben
werden.
Tabelle 1: Erklärung aller Statuscodes und der dazugehörigen Beschreibungen
Hierbei ist zu erkennen, dass es zwei Statusmeldungen gibt, welche für eine
erfolgreiche Abfrage stehen. Alle restlichen Statusmeldungen stehen für eine
fehlerhafte Anfrage. Dabei wird versucht, so detailliert wie möglich auf die
Fehlerursache einzugehen, um dem Benutzer das Beheben des Fehlers möglichst
leicht zu gestalten.
Zu erwähnen ist, dass die Statuscodes nicht wie üblich über den http-Header
übertragen werden. Die Fehlermeldungen dienen dem Benutzer somit nur zur
erweiterten Fehlerbehebung.
5. Implementierung
In diesem Kapitel werden die Einzelschritte zur Implementierung der earthfaves API
beschrieben. Das Kapitel gliedert sich dabei in fünf Unterkapitel. Beschrieben wird
dabei nicht konkret die Implementierung der einzelnen Funktionalitäten in der
Skriptsprache PHP, sondern die allgemeine Vorgehensweise mit wenigen wichtigen
Beispielen.

- 32 -
5.1. Einrichten der Subdomain
Zuerst war es notwendig, die API überhaupt erreichbar zu machen. Dafür musste ein
Konzept entworfen werden, welches es nach der Umsetzung erlaubt, eine beliebige
URL der Subdomain aufzurufen. Die URL soll dann in jedem Fall auf die zentrale Datei
index.php weiterleiten. Es wurde eine Subdomain eingerichtet, die den Bezeichner
api.earthfaves.biz trägt. Diese leitet beim Aufruf auf das Verzeichnis, in welchem die
Projektdateien liegen, weiter. Weiterhin wurde die Technik des URL Rewriting genutzt.
In der folgenden Abbildung ist zu sehen, welche Regel für das Rewriting eingesetzt
wird. Außerdem wird an einem Beispiel erläutert, welcher Teil der URL welchem
Parameter entspricht.
Abbildung 3: Beschreibung des URL Rewriting
Die URL ist in vier Bereiche geteilt. Der erste Teil ist immer api.earthfaves.biz. Dieser
ist nicht variabel und muss korrekt sein, sonst wird die Regel nicht bearbeitet.
Nachfolgend wird eine Zeichenkette aus den Buchstaben „a“ bis „z“ erwartet. Dabei
muss mindestens ein Buchstabe eingetragen sein. Dieser Teil wird intern als „task“
bezeichnet und ebenso als Parameter angehängt. Der nächste Teil gleicht dem
vorherigen bis auf die Tatsache, dass er als „subtask“ Parameter angehängt wird.
Zuletzt wird noch eine beliebige Anzahl an beliebigen Zeichen erwartet. Dieser Teil
wird als letzter Parameter angehängt und trägt den Namen „parameter“. Weitere
Parameter können ebenfalls optional angehängt werden. Im Beispiel ist dies der
Access Token, welcher für fast alle Anfragen an die API notwendig ist. Da dieser nicht
notwendig für die Hierarchieebenen der URL ist, wird er als zusätzlicher Parameter
angehängt.
Das vorgestellte Konzept stellt sicher, dass alle wichtigen Informationen aus der URL
extrahiert und korrekt an die verarbeitende Logik weiter gegeben werden.

- 33 -
5.2. Erweiterung der Datenbank
An der Datenbank waren einige Änderungen notwendig. Um die Speicherung aller
wichtigen Daten in der Datenbank zu gewährleisten, mussten folgende Tabellen neu
angelegt werden:
api_requests_per_day_settings
Die Tabelle enthält die Spalten „business_level_id“ und „value“. „business_level_id“
steht dabei für das Service-Paket, welche ein Geschäftskunde auswählen kann. Diese
sind aufsteigend geordnet, was bedeutet, dass 2 für Bronze, 3 für Silber und 4 für Gold
steht. Die Spalte „value“ enthält einen numerischen Wert, welcher für die Anzahl der
Zugriffe pro Tag steht. Somit wird in der Tabelle festgelegt, wie viele Zugriffe die
verschiedenen Geschäftskunden pro Tag haben.
api_task
Diese Tabelle enthält die Spalten „id“, „name“, „parent_id“, „business_level_id“ und
„locked“. „id“ steht dabei für einen numerischen Wert, der die Funktionen in der
Datenbank auszeichnet. „name“ steht für den Name des Tasks. „parent_id“ ist null,
insofern der Task kein Subtask ist. Ist es jedoch ein Subtask, so wird in dieser Spalte
der Task des übergeordneten Tasks eingetragen. Beispielsweise wäre der
übergeordnete Task zu „oneeffaver“ „business“. Die Spalte „business_level_id“ gibt an,
ab welchem Paket der Task zugänglich ist. Ist eine 4 eingetragen, so können nur Gold-
Nutzer den Task nutzen, wohingegen bei einer 3, sowohl Silber-, als auch Gold-Nutzer
den Task nutzen können. Zuletzt gibt noch „locked“ an, ob ein Task momentan für alle
Benutzer gesperrt ist. Zusammenfassend lässt sich sagen, dass die Tabelle
Informationen und den Status der einzelnen Tasks speichert.
business_has_api_access
Es existieren die Spalten „id“, „entity_business_id“, „public_key“, private_key„“, „salt”,
“access_token” und “expiration_date”. Die Tabelle ist zuständig für das Speichern der
Zugangsdaten für die API. „id“ ist der Primärschlüssel und zeichnet einen
Geschäftskunden aus. Pro Geschäftskunde darf nur ein Access Token existieren.
„entity_business_id“ steht über den Verweis in einer weiteren Tabelle für den
Geschäftskunden beziehungsweise für seinen registrierten Account bei earthfaves.
„public_key“ und „private_key“ stellen den öffentlichen und privaten Schlüssel dar, so
wie es nach OAUTH definiert ist. „access_token“ definiert den Zugangsschlüssel für
den Zugriff auf die Tasks der API dar. „salt“ wird zur Erzeugung eines Access Tokens

- 34 -
benötigt, welche beim mehrfachen Hashen23
eingestreut wird und somit die Sicherheit
erhöht. Zuletzt stellt „expiration_date“ das Ablaufdatum des Access Token dar. Ist das
Datum abgelaufen, so muss ein neuer Access Token angefordert werden, damit die
API weiterhin genutzt werden kann.
business_has_api_task_statistic
Enthalten sind die Spalten „id“, „api_task_id“, „entity_business_id“, „created” und
“execution_time”. Erstere ist ein numerischert Wert, welche die jeweilige Spalte
auszeichnen soll. „api_task_id“ stellt ebenfalls einen numerischen Wert dar, welcher
als Fremdschlüssel auf die „api_task“-Tabelle verweist. Somit stellt diese Spalte einen
API-Task dar. Die nächste Spalte steht, wieder über eine andere Tabelle verweisend,
für einen Geschäftskunden. „created“ bezeichnet das Datum der Erstellung einer Zeile
in dieser Tabelle und „execution_time“ stellt die Zeit zur Bearbeitung eines Tasks der
API dar. Daher ist die Tabelle für das Speichern statistischer Daten notwendig. Es wird
zu jedem API-Zugriff gespeichert, wer ihn ausgeführt hat, wie lange dieser gebraucht
hat und wann der Zugriff stattgefunden hat. Benötigt wird die Tabelle unter anderem,
um zu überprüfen, wie oft ein Benutzer täglich schon auf die API zugegriffen hat.
Weitere Anpassungen an der Datenbank waren nicht notwendig. Alle genutzten
Tabellen der Datenbank werden in der folgenden Abbildung dargestellt. Das
dargestellte Schema entspricht nicht der vollständigen Datenbank der Software.
Hierbei wurden nur die Tabellen abgebildet, welche auch von Relevanz für die API
waren. Die Gesamtzahl aller Tabellen übersteigt die Anzahl der dargestellten Tabellen
um ein vielfaches, weshalb eine visuelle Darstellung in diesem Rahmen nicht möglich
wäre.
23
Auf eine Zeichenkette wird beim Hashen ein Algorithmus angewendet. Dieser erzeugt zu jeder
möglichen Zeichenkette einen Hash-Wert. Es besteht eine bijektive Zuordnung.

- 35 -
Abbildung 4: Datenbankschema aller genutzten Tabellen

- 36 -
5.3. Programmierung der Logik im Backend
Nach dem Einrichten der URL und dem Testen der Funktionalität war es möglich, die
igentliche Logik für das Verarbeiten der Parameter und dem Erstellen der Ausgabe, zu
programmieren.
Grundlegend besteht das Projekt aus sechs Dateien:
 Controller.php: Beinhaltet die Controller-Klasse.
 View.php: Beinhaltet die View-Klasse.
 Model.php: Beinhaltet die Model-Klasse.
 TimeController.php: Beinhaltet die TimeController-Klasse.
 index.php: An diese Datei werden die Parameter der URL übergeben und die
Klassen werden instanziiert.
 api_config.php: Beinhaltet einige wichtige Konstanten.
Bei jedem Aufruf einer URL, welche auf die Subdomain api.earthfaves.biz geht, wird
die Datei index.php geladen. Das schon beschriebene URL Rewriting sorgt dafür, dass
in diesem Skript alle übergebenen Parameter in den superglobalen Variablen $_POST
und $_GET enthalten sind. Zuerst werden immer alle restlichen oben genannten
Dateien in die index.php inkludiert. Danach wird die Klasse TimeController instanziiert.
Direkt nach der Erstellung des Objekts wird die Stoppuhr gestartet, welche die
Bearbeitungszeit messen soll. Dies geschieht durch die Methode start(), die die
momentane Zeit in einem Attribut des Objekts speichert, so dass dieses an späterer
Stelle wieder genutzt werden kann. Die Zeit wird dabei in Mikrosekunden festgehalten,
da einige Aufrufe der API eine Bearbeitungsdauer von unter einer Sekunde haben.
Somit kann die genaue Dauer differenzierter betrachtet werden.
Der nächste Schritt ist das Instanziieren der Controller-Klasse. Dem Controller-Objekt
werden bei der Erzeugung die superglobalen Variablen $_POST und $_GET im
Konstruktor übergeben. Im Konstruktor werden alle wichtigen Parameter aus den
superglobalen Variablen ausgelesen und in separaten Attributen des Objekts
gespeichert. Ebenfalls werden an dieser Stelle die View- und die Model-Klasse
instanziiert. Das Model-Objekt stellt in seinem Konstruktor die Verbindung zur
Datenbank her. Dafür notwendig sind Konstanten, welche in der api_config.php
gespeichert sind. Die Konstanten wurden in eine Konfigurationsdatei ausgelagert,
damit, insofern sich die Zugangsdaten zu einem späteren Zeitpunkt ändern sollten, sie
nur noch an einer Stelle im gesamten Projekt geändert werden müssen. Das View-
Objekt erhält im Konstruktor die Variablen $task, $subTask und $accessToken. Diese

- 37 -
sind für die spätere Zuweisung der Strukturen für die Ausgabe notwendig, da dabei
Fallunterscheidungen gemacht werden und sich diese über den Task leicht
identifizieren lassen. Nachfolgend wird die Methode startTask() des Controller-Objekts
ausgeführt, welche letztendlich den Anstoß zur Verarbeitung aller Daten gibt. Innerhalb
dieser Methode wird durch tief geschachtelte Fallunterscheidungen überprüft, inwiefern
alle Parameter den Vorgaben entsprechen. Ebenfalls wird dabei überprüft, welcher
Task und welcher Subtask ausgeführt werden sollen. Eine schematische Darstellung
aller Überprüfungen und Validierungen stellt die folgende Abbildung dar. Die
Endpunkte in der Darstellung sind in jedem Fall die Ausgabe einer Fehlermeldung oder
das Aufrufen einer Funktion. Für jeden Task und den dazugehörigen Subtask existiert
eine Funktion, welche alle benötigten Daten über das Model-Objekt aus der Datenbank
ausliest, diese weiterverarbeitet und zuletzt an das View-Objekt weiter gibt. Für das
Abrufen von Daten aus der Datenbank existieren verschiedene Funktionen, welche
direkt aufgerufen werden können und dementsprechend ein mysqli-Objekt
zurückliefern. Die Funktionen zum Bearbeiten der verschiedenen Tasks rufen dabei in
gewissen Fällen unter anderem die gleichen Funktionen auf, da die gleichen Daten
genutzt werden müssen. Beispielsweise wird sowohl beim Erstellen von Informationen
über einen Benutzer der Vor- und Nachname abgefragt, als auch beim Erstellen von
Informationen über die Empfehler eines Earthfaves. Dementsprechend zeigen sich hier
die Vorteile der objektorientierten Programmierung, da somit zum Teil redundanter
Programmcode vermieden werden kann. Sind alle notwendigen Daten
zusammengestellt, werden diese in einem Array gespeichert, welches an das View-
Objekt übergeben wird. Eine Vorsortierung hat somit stattgefunden, wobei auch die
Schlüsselwerte des Arrays in die spätere Ausgabe übernommen werden. Des Weiteren
werden in den einzelnen Funktionen ebenfalls Überprüfungen durchgeführt, welche im
entsprechenden Fall eine Fehlermeldung hervorrufen können. Diese wurden nicht in
die allgemeine Validierung und Überprüfung am Anfang der Bearbeitung eingefügt, da
diese nur spezifisch auf die jeweiligen Tasks zutreffen sind und somit eine Überprüfung
für andere Tasks teilweise unnötig wäre. Sind die Überprüfungen fehlerfrei
durchgeführt worden, so werden alle übergeben Daten im View-Objekt durch das
Aufrufen der Methode setData() in die Ausgabestruktur geordnet. Dabei kommt die
Zuweisung des Tasks und des Subtasks zum Tragen, welche im Konstruktor an das
Objekt übergeben wurden. Dabei wird die schon erwähnte Fallunterscheidung
ausgeführt und die entsprechende Struktur bei der Zuweisung gewählt.

- 38 -
Eingabe
der
URL
Task
korrekt?
Error
Ausgabe
nein
Task
gesperrt?
Subtask
gesperrt?
ja
nein
ja
ja
task
=
„authenticate“
Public
Key
und
Private
Key
gültig?
nein
ja
subTask
=
ja
default
Prozess
zur
Authentifizierung
eines
Geschäftskunden
business
Request
Methode
=
Neuen
Access
Token
erzeugen
POST
Alten
Access
Token
zurückgeben
GET
nein
Access
Token
in
der
Datenbank
vorhanden?
nein
nein
Access
Token
abgelaufen?
ja
Bezahlte
Zeit
des
Geschäftskunden
abgelaufen?
ja
nein
ja
Geschäftskunde
für
den
Prozess
autorisiert?
nein
nein
Maximale
Request-
Anzahl
überschritten?
ja
ja
task
=
nein
subTask
=
subTask
=
subTask
=
business
user
earthfave
default
Benutzer
in
Beziehung
zum
Geschäftskunden?
info
nein
Benutzerdaten
ausgeben
ja
default
Earthfave
in
Beziehung
zum
Geschäftskunden
info
nein
Earthfave
Daten
ausgeben
ja
alleffaver,
allefnotfaver,
allefexfaver,
default
Earthfave
in
Beziehung
zum
Geschäftskunden
oneeffaver
Earthfave
in
Beziehung
zum
Geschäftskunden
Earthfave
in
Beziehung
zum
Geschäftskunden
oneefexfaver
oneefnotfaver
nein
nein
nein
Empfehler
Daten
ausgeben
Ehemalige
Empfehler
Daten
ausgeben
Daten
zu
Personen,
die
explizit
nicht
empfehlen
ja
ja
ja
Abbildung 5: Ablaufdiagramm des Prüfungsmechanismus zum Zugriff auf die API

- 39 -
Dies ist notwendig, da somit auch die richtigen Attribute des Objekts zur Ausgabe
hinzugefügt werden. Andernfalls könnte der Fall eintreten, dass zwar Daten Attribute
zugewiesen werden, diese jedoch keine Nutzdaten enthalten. Des Weiteren wird die
Methode createOutput() aufgerufen, was dazu führt, dass die Strukturen innerhalb des
View-Objekts mit der Funktion json_encode() als JSON-kodiert ausgegeben werden.
Ist die Ausgabe erfolgreich erstellt, wird ein Attribut „requestSuccessful“ auf „true“
gesetzt. Dies ist notwendig, damit auch nur bei erfolgreichen Anfragen ein Eintrag in
die Datenbank vorgenommen wird. Ist dies der Fall, so führt das TimeController-Objekt
seine Methode end() aus, welche die Stoppuhr anhält.
Zuletzt wird dann der eben erwähnte Eintrag in die Datenbank vorgenommen. Dieser
enthält alle wichtigen Daten. Nicht erfolgreiche Anfragen werden nicht in die
Datenbank eingetragen.
5.4. Erweiterung der Internetpräsenz für Geschäftskunden
Die im Folgenden zu beschreibende Erweiterung der Software musste direkt in den
schon bestehenden Programmcode der Software eingefügt werden. Dafür wichtig sind
die Grundlagen der Entwicklungsrichtlinien der Earthfaves AG, welche im Kapitel 3.11.
beschrieben werden. Folgende Dateien sind für die Bereitstellung der Funktionalität
zuständig:
 business_stats.inc.php: Enthält die allgemeine Struktur des Menüs für
Geschäftskunden.
 en.php: Enthält englische Sprachkonstanten.
 de.php: Enthält deutsche Sprachkonstanten.
 languages.php: Enthält Sprachkonstanten, welche an das FrontEnd
weitergegeben werden und somit in JavaScript nutzbar sind.
 UIModulesBusiness.php: Enthält Methoden zur Erzeugung von HTML-
Strukturen für das Menü der Geschäftskunden.
 UIProviderBusiness.php: Enthält alle notwendigen Datenbankabfragen, um die
zuvor erwähnten Strukturen mit Inhalten zu füllen.
 openThisBusiEfOptionRequest.php: Eine Datei zum Sammeln der Aufrufe,
welche durchgeführt werden, wenn man einen Menüpunkt selektiert. Die
aufgerufenen Funktionen zum Erzeugen der Inhalte sind dabei in der Datei
UIModulesBusiness.php zu finden.

- 40 -
 ext2.js: Enthält allgemeine JavaScript Funktionen.
 ajax.js: Enthält JavaScript Funktionen, welche einen AJAX-Aufruf durchführen.
 showApiData.php: Die Datei wurde neu angelegt und ist zuständig für das
Anzeigen der HTML-Strukturen, die die API-Daten eines Benutzers anzeigen.
Der erste Schritt war das Anlegen eines neuen Menüpunktes, da dieser zuvor noch
nicht vorhanden war. Dieser wurde in der Datei business_stats.inc.php hinzugefügt.
Durch das Hinzufügen eines Link-Tags wurde der Menüeintrag selektierbar gemacht.
Wird dieser angewählt, so werden zwei Funktionen ausgeführt. Zum einen ist dies die
Funktion setUberschriftAndInfoText(), welche die allgemeinen Informationen über die
API anzeigt. In diesem Fall sind das nur eine Überschrift und ein kurzer Satz, welcher
den Benutzer darauf hinweist, dass an dieser Stelle die notwendigen Daten für die API-
Nutzung zu finden sind. Zum anderen wird die Funktion
openThisBusiEfOptionRequest() aufgerufen. Diese trägt den gleichen Namen wie die
zugehörige PHP Datei, welche durch einen AJAX-Aufruf vom Client angefragt wird.
Sowohl die Funktion, als auch die zugehörige Datei existierten schon vorher, weshalb
sie in ihrer Funktionsweise nur modifiziert werden mussten. Das wurde durch das
Hinzufügen eines weiteren Falls realisiert, da innerhalb der Datei der PHP-Befehl
switch() für die Verarbeitung zuständig ist. Somit wird eine Methode
showApiCredentials() der Klasse UIModulesBusiness aufgerufen, die für das Anzeigen
der konkreten Inhalte ist. Diese enthält eine Methode isApiUser() der Klasse
UIProviderBusiness. Weil diese Klasse für das Anfordern von Daten aus der
Datenbank zuständig ist, wird an dieser Stelle mit dem PROPEL Framework eine
Datenbankabfrage realisiert, welche durch eine zusätzliche Bedingungsabfrage
entscheidet, ob der aktuelle Benutzer sich schon für die Nutzung der API registriert hat.
Hat er dies, so wird ein Array mit allen dafür notwendigen Daten zurückgegeben. Ist
dem nicht so, gibt die Funktion den Wert „null“ zurück. Nach der Rückgabe an die
Funktion showApiCredentials existiert weiterhin eine Bedingungsabfrage, welche nur
die Checkbox zum Registrieren für die API anzeigt, insofern „null“ zurück gegeben
wurde. Ist dies nicht der Fall, so wird davon ausgegangen, dass ein Array mit allen
wichtigen Daten existent ist. Folglich können alle Strukturen erzeugt werden und dem
Benutzer somit der Public Key, der Private Key, der Access Token, Das Ablaufdatum,
seine earthfave ids und seine „Entity_business_id“.

- 41 -
Abbildung 6: Erweiterung der Internetpräsenz für Geschäftskunden
Die Checkbox ist selektierbar und führt dementsprechend eine Funktion aus, welche je
nachdem, ob der Benutzer sich registriert hat oder nicht, einen AJAX-Aufruf an die
Datei showApiData.php ausführt. Übergeben wird der Parameter „task“ entweder mit
dem Wert „delete“ oder „insert“. Ersterer steht dabei für das Ausblenden der HTML-
Strukturen und das Löschen der dazugehörigen Dateien aus der Datenbank. „insert“
hingegen erzeugt diese Daten neu. Dementsprechend wird, wenn „task“ „delete“ ist,
ein einfaches PROPEL-Statement ausgeführt, was alle Daten aus der Datenbank
entfernt. Ist der Wert von „task“ „insert“, so werden zuerst für den Public Key und den
Private Key zwei zufällige Zeichenketten erstellt und diese zusammen mit allen
anderen Daten in die Datenbank eingetragen. Da zu diesem Zeitpunkt aber noch kein
Access Token vorhanden ist, wird eine Anfrage an die API gesendet, die den Public
Key und den Private Key übermittelt. Somit wird ein neuer Access Token erzeugt.
Zuletzt kann die schon beschriebene Funktion showApiCredentials() aufgerufen
werden, welche dafür sorgt, dass dem Benutzer alle notwendigen Daten angezeigt
werden.
Die Inhalte werden, wie auch der Rest der Internetpräsenz, in zwei verschiedenen
Sprachen zugänglich gemacht, weshalb an dieser Stelle auch die PHP Dateien für die
Sprachkonstanten genutzt werden mussten. In diesem Fall gab es allerdings nur
wenige zu übersetzende Inhalte, weshalb wenige Sprachkonstanten erstellt wurden.
5.5. Erstellung der Access Token
Der Public Key und der Private Key bestehen jeweils aus 32 Zeichen und setzen sich
dabei aus 62 verschiedenen Zeichen zusammen. Dies sind Großbuchstaben,

- 42 -
Kleinbuchstaben und Ziffern von Null bis Neun. Betrachtet man nun die Anzahl aller
möglichen Kombinationen, so lässt sich ein Wert von rund 1,407e+106 errechnen.
Dementsprechend gibt es rund 14 Septendezilliarden verschiedene Möglichkeiten der
Zusammensetzung beider Zeichenketten. Daran ist zu erkennen, dass es zwar
theoretisch möglich wäre, dass zwei Geschäftskunden identische Public Keys und
Private Keys erhalten, dies aber statistisch im Bereich einer verschwindend geringen
Wahrscheinlichkeit liegt.
Für die Erzeugung eines Access Token werden verschiedene Bestandteile genutzt.
Dies sind zum einen, der Public Key und der Private Key und zum anderen eine
weitere Zeichenkette, welche als „salt“ bezeichnet wird. „salt“ wird in gleicher Weise
erzeugt wie die Zeichenkette des Public Keys oder des Private Keys, nur in diesem Fall
mit 16 statt 32 Zeichen. Bei der Verschlüsselung des Access Token wird zuerst der
Public Key an den Private Key angehängt, so dass eine Zeichenkette mit 64 Zeichen
entsteht. Danach wird innerhalb einer Schleife die Zeichenkette mehrfach mit dem
Algorithmus md5 gehasht. Die Anzahl der Durchläufe der Hashvorgänge wird in einer
Konstante in der Datei api_config.php definiert. Da das Hashen alleinstehend keine
Verschlüsselung darstellt, wird hierbei auf das Konzept des „Salzens“ zurückgegriffen.
Dabei wird die als „salt“ bekannte Zeichenkette vor jedem Hashvorgang an die
Zeichenkette angehängt. So entsteht ein anderer Hashwert, als beim normalen Hashen
entstehen würde. Da einem potentiellen Angreifer die „salt“ nicht bekannt ist, erhöht
dies die Sicherheit der Zeichenketten.
Zusätzlich dazu wird für jeden Benutzer eine eigene „salt“ erzeugt, was es für einen
potentiellen Angreifer unmöglich macht, diesen allgemein zu erraten oder auszulesen.
Da es auch im Fall der Erzeugung einer Zeichenkette für „salt“ eine sehr hohe Anzahl
an Möglichkeiten gibt, ist es hierbei ebenfalls sehr unwahrscheinlich, dass zwei
Geschäftskunden dieselbe Zeichenkette erhalten. Ist dies doch der Fall, spielt es nur
eine Rolle, insofern auch beide Kunden die gleichen Zeichenketten für den Public Key
und den Private Key erhalten.
5.6. Entwicklung einer Administrationsoberfläche
Die Entwicklung einer Administrationsoberfläche war notwendig, um alle globalen
Einstellungen für die API an einer zentralen Stelle zu gewährleisten. Theoretisch sind
die Einstellungen auch alle über die Datenbank veränderbar. Jedoch stellt die
Administrationsoberfläche auch Personen, welche keine Programmierkenntnisse

- 43 -
haben, ein Werkzeug zur Verfügung, um die API zu administrieren. Weiterhin sollten
auch statistische Daten erhoben werden, welche in dieser Form nicht direkt aus der
Datenbank auszulesen sind.
Für die Entwicklung wurden folgende Dateien benötigt:
 apiadmintool.inc.php: Stellt die Datei dar, welche über das Aufrufen einer URL
zu erreichen ist. Dabei werden in dieser Datei das HTML-Grundgerüst und die
drei verschiedenen Menüeinträge erzeugt.
 UIModulesAdmin.php: Stellt Methoden zur Erzeugung von HTML-Strukturen für
Administrationsoberflächen zur Verfügung.
 UIProviderAdmin.php: Stellt Methoden zur Abfrage von Inhalten aus der
Datenbank für Administrationsoberflächen zur Verfügung.
 apiAdminRequest.php: Wird vom AJAX-Framework aufgerufen und ist für
Datenbankabfragen zuständig.
 apiAdminSave.php: Wird ebenfalls per AJAX aufgerufen und gibt Änderungen
am Datenbestand an die Datenbank weiter.
 ext.js: Stellt allgemeine JavaScript-Funktionen zur Verfügung.
 ajax.js: Stellt JavaScript-Funktionen zur Verfügung, welche AJAX nutzen.
 page_init.php: Zuständig für das Inkludieren von Dateien. Wird immer beim
Laden der Seite mit geladen und entscheidet, welche Klassen und Ähnliches
inkludiert werden sollen
Über die URL “www.earthfaves.biz/page/apiadmintool/“ ist die
Administrationsoberfläche erreichbar. Dabei ist es notwendig, der Benutzergruppe
„Admin“ anzugehören. Andernfalls wird nur „no admin“ angezeigt und es nicht möglich,
die Administrationsoberfläche zu nutzen. Innerhalb der Datei apiadmintool.inc.php
werden die notwendigen HTML-Strukturen für die Oberfläche erzeugt. Dies sind zum
einen eine Navigation und zum anderen ein zu Anfang leerer Bereich, welcher
dynamisch mit Inhalten gefüllt werden soll. Dabei wurden drei Menüeinträge erzeugt:
1. Api Tasks: Soll das Administrieren der Tasks möglich machen
2. Api Business Users: Soll anzeigen, welche Geschäftskunden momentan die
API nutzen
3. Api Statistics: Soll die letzten Zugriffe auf die API anzeigen
Jeder Menüpunkt ist durch einen Link-Tag selektierbar, wobei jeweils die Funktion
apiAdmin() aufgerufen wird. Je nachdem, welchen Eintrag man selektiert hat, werden

2014 gnepper,tom entwicklung eines application programming interface, bachelor_thesis

2014 gnepper,tom entwicklung eines application programming interface, bachelor_thesis

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie 2014 gnepper,tom entwicklung eines application programming interface, bachelor_thesis

Ähnlich wie 2014 gnepper,tom entwicklung eines application programming interface, bachelor_thesis (20)

Mehr von Markus Schneider

Mehr von Markus Schneider (20)

2014 gnepper,tom entwicklung eines application programming interface, bachelor_thesis