Um Produkte per EAN-Code-Reader von einer TYPO3-Webseite abzufragen, habe ich ein kleines Webservice geschrieben, welches mir per HTTP GET Produktdaten im Format JSON zurückliefert.

 Vorkenntnisse für unsere ReST-API

(ReST = Representational State Transfer)

Ein ReST-Webservice stellt verschiedene Methoden über HTTP Parameter zu Verfügung.

Die Methoden

Das Interface von ReST ist generisch. Es müssen keine Protokoll-Konventionen bekannt sein, damit Client und Server sich verständigen können. Die folgende Aufzählung beschreibt die Bedeutung der HTTP-Methoden, wie sie von ReST verwendet werden.

• GET: GET fragt die Repräsentation einer Resource ab. Requests sollten frei von Seiteneffekten sein. GET Requests können beliebig oft abgeschickt werden.
• POST: Mit POST kann einer Resource etwas hinzugefügt werden. Beispielsweise könnte eine Ware zu einem Warenkorb hinzugefügt werden. POST ist nicht frei von Seiteneffekten. Beispielsweise können durch einen POST Aufruf Felder in einer Datenbank verändert oder Prozesse auf dem Server gestartet werden.
• PUT: Neue Resourcen können mit PUT erzeugt, oder der Inhalt bestehender Resourcen kann mit PUT ersetzt werden.
• DELETE: Resourcen können mit DELETE gelöscht werden.

Zudem können noch verschiedene Datenformate für die Kommunikation verwendet werden:

• JSON (JavaScript Object Notation)
  JSON wird zur Übertragung und zum Speichern von strukturierten Daten eingesetzt; es dient als Datenformat bei der Serialisierung. Insbesondere bei Webanwendungen und mobilen Apps wird es in Verbindung mit JavaScript, Ajax oder WebSockets zum Transfer von Daten zwischen dem Client und dem Server häufig genutzt.
• JSON-P (JavaScript Object Notation mit Padding)
  JSONP (JSON mit Padding) ermöglicht die Übertragung von (JSON-)Daten über Domaingrenzen, ist jedoch mit Sicherheitsrisiken behaftet.
• XML (Extensible Markup Language)
  XML ist eine Auszeichnungssprache und somit vielseitiger einsetzbar als JSON, das ein Datenaustauschformat ist. XML ist weiter verbreitet, wird jedoch von JSON aufgrund seiner Einfachheit dort zurückgedrängt, wo keine komplizierten Auszeichnungen notwendig sind.

Wir benötigen in diesem Fall JSON-P.

Was muss gemacht werden

Grundsätzlich muss eine Anfrage samt aller Parameter entgegen genommen und nach abarbeiten des Scripts ein Antwort zurückgeschickt werden.

Zuerst werden die übergebenen Daten überprüft. In diesem Fall wird beim Aufruf der URL der Parameter “ean” erwartet.

if (isset($_GET["ean"])) {

 $ean = $_GET["ean"];

 // Hier wird dann die Logik ausgeführt (z.B. Daten aus der DB mittels "ean" holen)
 // Wichtig ist nur, dass am Ende ein valides Javascript Object übergeben wird. 
 // Dies erreichen wir, in dem die Rückgabe zuerst in einem Array gespeichert wird.

$response_array = {'id' => 1, 'title' => 'Mein Titel'};
}

Am Ende wird dieses Array dann mittels “json_encode($response_array)” als JSON ausgegeben. Falls ein JSON-P Rückgabe notwendig ist, muss das JSON mittels des “Callback” Werts aus der Anfrage übergeben werden.

//start output
$callback = $_REQUEST['callback'];

if ($callback) {
    //JSON-P
    header('Content-Type: text/javascript');
    echo $callback . '(' . json_encode($response_array) . ');';
} else {
    //JSON
    header('Content-Type: application/x-json');
    echo json_encode($response_array);
}

Entscheidend ist, dass die Daten mittels

 json_encode(.....)

übergeben werden!

Rückgabe der API testen

Um die API zu testen, gibt es ein paar hilfreiche Tools wie zum Beispiel die Chrome Extension Postman, mit deren Hilfe das Testen etwas einfacher und schneller geht. Natürlich kann man aber auch problemlos über die Console mittels “curl” testen.

Wenn alles funktioniert, dann bekommt man als Belohnung für den Aufwand die Daten analog zu meinem Beispiel hier zurückgeliefert.

{
"getParams": {
"ean": "9009457092232"
},
"products": {
"58766": {
"uid": "58766",
"name": "Breitverteilerdüse 4,5,6",
"artnr": "52816",
"ean": "9009457092232",
"lagerplatz1": "86.1.6",
"lagerplatz2": "21.27.2",
"new": "0",
"top": "0",
"short": "",
"description": "58766",
"fotos": "52816_bild.jpg,52816_skizze.jpg",
"documents": null,
"category": "49947",
"category_title": "Breitverteiler Düse",
"category_parent": "49921",
"productunit_description": "pro Stück",
"taxrate_percent": "20",
"price_onrequest": "0",
"price": "57.50",
"currency": "1",
"currency_symbol": "€",
"priceWithTax": 69,
"category_breadcrumbs": "Kategorie: > Hauptkategorien > Gülle > passend zu System Bauer > Breitverteiler Düse",
"foto": "http://www.geheimeurl.com/uploads/tx_itcshop/52816_bild.jpg",
"skizze": "http://www.geheimeurl.com/uploads/tx_itcshop/52816_skizze.jpg"
}

Quellen:

• https://de.wikipedia.org/wiki/JavaScript_Object_Notation#JSONP
• http://www.oio.de/public/xml/rest-webservices.htm

---

 

UPDATE

Im Nachhinein würde ich sagen, dass es wohl etwas geschickter wäre, direkt TYPO3 zu bemühen, um die Daten auszuliefern. Dadurch gibt es dann auch Zugriff auf die Funktionen der Extbase-Erweiterung mit den Produkten. Es wäre dann bei Änderungen nicht nötig, die Funktionalität der API an die der Extension anzupassen, zumindest solange sich nur Hilfsfunktionen (wie Preisberechnung oder Versandkostenberechnung) ändern.

Dadurch, dass ich das jetzt händisch, ohne auf TYPO3 zurückzugreifen, erledigt habe, mussten natürlich sämtliche Ausnahmen und Berechnung nachgebaut werden.

Damit das beim nächsten Mal besser gelöst wird (oder falls es hier jemand liest und gleich richtig angehen möchte), stelle ich hier Links zu einer besseren Lösung bereit. Für TYPO3-Entwickler sei hier erwähnt, dass dafür “Extbase PHP based View” genutzt wird:

Quellen:

• https://docs.typo3.org/typo3cms/ExtbaseFluidBook/latest/8-Fluid/9-using-php-based-views.html
• http://wiki.t3easy.de/extbase-und-fluid/extbase-php-based-view/