Seite wählen

NETWAYS Blog

Zend JSON-Ausgabe

Um JSON mit dem Zend auszuliefern, könnte man auf die harte Tour, Header selbst setzen, Daten enkodieren und layouts deaktvieren oder man nutzt Funktionalitäten, die das Framework schon bietet. Um zum Beispiel JSON direkt zu senden, bedient man sich Zend_Controller_Action_Helper_Json:

class TestController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $data = array(
            'test' => true
        );
        /**
         * Call Zend_Controller_Action_Helper_Json::direct
         */
        $this->_helper->json($data);
    }
}

Über die Url ../test erhalten wir die Ausgabe in JSON inklusive dem korrekten Content-type application/json.
Nachteil dieses Aufruf ist, dass die dispatch loop sofort unterbrochen wird und somit eventuelle Erweiterungen durch Plugins nicht mehr aufgerufen werden.
Besser ist es, den ContextSwitch Action-Helfer zu benutzen, welcher XML und JSON unterstützt, layouts deaktiviert und Header enstrechend setzt:

class TestController extends Zend_Controller_Action
{
    public function init()
    {
        $this->_helper
             ->contextSwitch()
             ->addActionContext('index', 'json')
             ->initContext();
    }
    public function indexAction()
    {
        $this->view->test = true;
    }
}

Die JSON-Ausgabe ist nun über die Url ../test?format=json erreichbar.
Um sich den format-Parameter zu sparen, kann man für alle actions im Controller das json-Format erzwingen:

public function init()
{
    /**
     * Force json format
     */
    $this->_request->setParam('format', 'json');
    ...
}

Zum weiterlesen: Zend ContextSwitch

Eric Lippmann
Eric Lippmann
CTO

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Architekturstile: REST

Vor einiger Zeit sind wir ja bereits auf SOAP intensiv eingegangen. SOAP ist zwar zu Beginn oft Komplex und konfrontiert die Entwickler mit einer etwas anstrengenderen Lernkurve, spielt jedoch auf der Geraden den ein oder anderen Vorteil in Bezug auf komplexe Übermittlungen in heterogenen Umgebungen aus.
REST steht für REpresentational State Transfer und beschreibt ein Architekturmodell, dass man täglich an vielen Stellen des WWW, seinem logischen Vorbild, wiederfindet. Während SOAP „nur“ ein Transfermedium von Nachrichten ist, hat REST eine konkrete Vorstellung wie mit entsprechenden Schnittstellen umgegangen wird.
Hierfür stehen die klassischen Web-Methoden GET, POST, PUT und DELETE zur Verfügung. Abhängig von Ihrer Verwendung ist somit auch die grundlegende Funktion beschrieben.
Ein Beispiel:
[code lang=“xml“]
GET
[/code]
Hier ist klar zu erkennen, dass die Ressourcenauflösung über Pfade dazu verwendet wird ein Objekt eindeutig zu identifizieren und den Status zu ermitteln. Soll ein neuer Status hinzugefügt werden, kann das folglich mit einem POST-Request erfolgen. Die Ausgabe des REST-Kommandos ist im Vergleich zu SOAP nicht im Detail spezifiziert, jedoch wird häufig XML verwendet, da sich die Weiterverarbeitung deutlich einfacher gestaltet. Über den Verweis auf anderer REST-Ressourcen mit Hilfe der sogenannten XLinks’s können auch hierarchische Beziehungen abgebildet und aufgelöst werden.
In dieser Einfachheit liegt der klare Vorteil von REST, da sich der Entwickler, mit Ausnahme der strukturierten Verzeichnisauflösung, an keine definierten Übertragungsformate halten muss und die Anwendung leichtgewichtig gestalten kann. Daraus ergibt sich jedoch auch eine stark verzahnte Kommunikationsebene zwischen Client und Server, da der Spezifikation kein Routingmodell hinterlegt ist.
Die Entscheidung für SOAP oder REST ist, wie bereits im vorhergehenden Artikel erläutert, abhängig vom Bedarf an Komplexität und der Möglichkeit komplexere Transaktionen zu bündeln und zu routen. Der überwiegende Teil an Systemen wird jedoch leicht mit REST auskommen und von den agilen Möglichkeiten profitieren.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

Architekturstile: SOAP

Wie vor einigen Wochen versprochen, möchte ich heute einmal auf das SOAP-Protokoll eingehen. SOAP steht für Simple Object Access Protocol, besser gesagt stand. Seit den letzteren Versionen hat man dieses Akronym aufgrund der hohen Komplexität, die zugegeben mit Simple nicht viel zu tun hat, aufgegeben.
Als Protokoll beschreibt SOAP unter Nutzung von XML eher den Aufbau einer Nachricht als die eigentliche Übertragung. Eine SOAP-Nachricht besteht aus einer Hülle, dem so genannten SOAP-Envelop und beinhaltet einen entsprechenden Header und Body. Während der SOAP-Header optional ist, muss der Body ausgeführt sein und kann noch ein entsprechendes SOAP-Fault Element enthalten um Fehlersituationen zu übermitteln.
Ein Beispiel für eine gültige SOAP-Nachricht:
[code lang=“xml“]
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.icinga.org/status">
<m:GetStatus>
<m:ServerStatus>srv-lin-01</m:StockName>
</m:GetStatus>
</soap:Body>
</soap:Envelope>
[/code]
Zwar ist HTTP oder HTTPS der häufigste Standard um entsprechende Nachrichten zu übermitteln, es ist jedoch auch eine alternative Nutzung von JMS, SMTP oder anderen Transportmodellen möglich.
Im Unterschied zu REST, dazu bald mehr, ist SOAP kein leichtgewichtiges Unterfangen. Es Bedarf wohl definierten Schnittstellen und Namespaces um sich bei verschiedenen Services in größeren Umgebungen nicht in die Quere zu kommen und ist aufgrund des entsprechenden XML-Overheads bei der Übertragung von großen Datenmengen nicht besonders performant. Diese Nachteile verlieren durch immer größere Bandbreiten und entsprechende Performance jedoch zunehmend an Bedeutung und auch die entsprechende XML-Parser haben in Sachen Geschwindigkeit ordentlich zugelegt.
Der große Vorteil von SOAP liegt darin, dass ein entsprechender Service genau auf die Beantwortung bestimmter Requests vorbereitet werden muss und somit schon auf Schnittstellenebene gewisse Unstimmigkeiten eliminiert werden können. Ein „ungefähr“ Request wird freundlich vom Server zurückgewiesen und vermeidet eine fehlerhafte Verarbeitung auf Definitionsebene.
Die beliebige Komplexität eines SOAP-Envelops ermöglicht jedoch die Zusammenfassung komplexer Transaktionen und Strukturen in einer Nachricht. So kann der Overhead der Einzelabfrage reduziert werden und komplexe Zusammenhänge einfacher dargestellt werden als durch Abbildung einer Vielzahl von REST-Requests.
Eine Entscheidung zugunsten von SOAP sollte nur bei Notwendigkeit der entsprechenden Komplexität fallen, ist dann aber oft auch sinnvoll.
Handle with Care!

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.

MySQL Daten nach XML exportieren

Immer wieder findet man in Foren und verschiedenen Websites kleine Scripts, die eine MySQL-Tabelle in XML konvertieren. Bereits seit frühen 4er Versionen bietet MySQL dafür die Option –xml/ -X an, welche Ergebnisse der übergebenen Select-Anweisungen in standardkonforme XML-Dateien verwandelt, welche für viele Bedürfnisse ausreichen dürften.
Ein Beispiel:
[code lang=“shell“]
mysql –xml -e &quot;select alias, display_name, address from nagios.nagios_hosts limit 1,2&quot;
[/code]
gibt folgendes Ergebnis:
[code lang=“xml“]
&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;resultset statement=&quot;select alias, display_name, address from nagios.nagios_hosts limit 1,2
&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;&gt;
&lt;row&gt;
&lt;field name=&quot;alias&quot;&gt;Business Processe&lt;/field&gt;
&lt;field name=&quot;display_name&quot;&gt;business_processes&lt;/field&gt;
&lt;field name=&quot;address&quot;&gt;10.6.255.99 # dummy IP&lt;/field&gt;
&lt;/row&gt;
&lt;row&gt;
&lt;field name=&quot;alias&quot;&gt;untergeordnete Business Processe&lt;/field&gt;
&lt;field name=&quot;display_name&quot;&gt;business_processes_detail&lt;/field&gt;
&lt;field name=&quot;address&quot;&gt;10.6.255.99 # dummy IP&lt;/field&gt;
&lt;/row&gt;
&lt;/resultset&gt;
[/code]
Auch mysqldump unterstützt die Ausgabe in XML, exportiert die Informationen jedoch aufgabengemäß in zusätzlichen Elementen mit Datenbank- und Tabelleninformationen.
Ein Beispiel:
[code lang=“shell“]
mysqldump nagios nagios_dbversion –xml
[/code]
gibt folgendes Ergebnis:
[code lang=“xml“]
&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;mysqldump xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;&gt;
&lt;database name=&quot;nagios&quot;&gt;
&lt;table_structure name=&quot;nagios_dbversion&quot;&gt;
&lt;field Field=&quot;name&quot; Type=&quot;varchar(10)&quot; Null=&quot;NO&quot; Key=&quot;&quot; Default=&quot;&quot; Extra=&quot;&quot; /&gt;
&lt;field Field=&quot;version&quot; Type=&quot;varchar(10)&quot; Null=&quot;NO&quot; Key=&quot;&quot; Default=&quot;&quot; Extra=&quot;&quot; /&gt;
&lt;options Name=&quot;nagios_dbversion&quot; Engine=&quot;InnoDB&quot; Version=&quot;10&quot; Row_format=&quot;Compact&quot; Rows=&quot;1&quot; Avg_row_length=&quot;16384&quot; Data_length=&quot;16384&quot; Max_data_length=&quot;0&quot; Index_length=&quot;0&quot; Data_free=&quot;0&quot; Create_time=&quot;2009-09-11 12:04:09&quot; Collation=&quot;latin1_swedish_ci&quot; Create_options=&quot;&quot; Comment=&quot;InnoDB free: 11264 kB&quot; /&gt;
&lt;/table_structure&gt;
&lt;table_data name=&quot;nagios_dbversion&quot;&gt;
&lt;row&gt;
&lt;field name=&quot;name&quot;&gt;ndoutils&lt;/field&gt;
&lt;field name=&quot;version&quot;&gt;1.4b7&lt;/field&gt;
&lt;/row&gt;
&lt;/table_data&gt;
&lt;/database&gt;
&lt;/mysqldump&gt;
[/code]

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.