Was ist XML?

Wenn Sie APIs testen, sollten Sie zwei Hauptdatenübertragungsformate kennen:

• XML - wird in SOAP- (immer) und REST-Anforderungen (seltener) verwendet ;
• JSON - wird in REST-Anforderungen verwendet.

Heute werde ich Ihnen XML vorstellen.



XML , übersetzt aus dem Englischen e X Tensible M arkup L Anguage ist eine erweiterbare Markup-Sprache. Dient zum Speichern und Übertragen von Daten. Sie können es also nicht nur in der API, sondern auch im Code sehen.



Dieses Format wird vom World Wide Web Consortium (W3C) empfohlen und wird daher häufig für die Übertragung von Daten über die API verwendet. In der SOAP-API ist dies im Allgemeinen das einzig mögliche Format für Eingabe- und Ausgabedaten!

Siehe auch:

Was ist eine API - eine allgemeine Einführung in die API

Einführung in SOAP und REST: Was es ist und womit man essen sollte - ein Video über den Unterschied zwischen SOAP und REST.

Also lasst uns herausfinden, wie es aussieht, wie man es liest und wie man es bricht! Ja, ja, aber wo ohne? Schließlich müssen wir herausfinden, wie das System auf das Kurvenformat der gesendeten Daten reagiert.

Inhalt

• Wie XML funktioniert
  
  
  • Stichworte
  • Wurzelelement
  • Gegenstandswert
  • Elementattribute
  • XML-Prolog
  • XSD-Schema
  • Übung: Schreiben Sie Ihre Anfrage
• Gut geformtes XML
  
  
  • 1. Es gibt ein Wurzelelement
  • 2. Jedes Element hat ein schließendes Tag
  • 3. Tags unterscheiden zwischen Groß- und Kleinschreibung
  • 4. Korrigieren Sie die Verschachtelung von Elementen
  • 5. Attribute sind in Anführungszeichen eingeschlossen
• Gesamt

Wie XML funktioniert

Nehmen wir ein Beispiel aus Dadatas Dokumentation mit vollständigen Namenshinweisen :

<req>
<query> </query>
<count>7</count>
</req>

Und lassen Sie uns herausfinden, was dieser Eintrag bedeutet.

Stichworte

In XML muss jedes Element in Tags eingeschlossen werden. Ein Tag ist ein Text in spitzen Klammern:

<tag>

Der Text in den spitzen Klammern ist der Tag-Name.

Es gibt immer zwei Tags:

• Opener - Text in spitzen Klammern

  <tag>

• Schließen - der gleiche Text (das ist wichtig!), Aber das Symbol "/" wird hinzugefügt

  </tag>

Oh, okay, wurde erwischt! Nicht immer. Es gibt auch leere Elemente, sie haben ein Tag, das gleichzeitig geöffnet und geschlossen wird. Aber dazu später mehr!



Mit Hilfe von Tags zeigen wir dem System "hier beginnt das Element und hier endet es". Es ist wie mit Verkehrszeichen:



- Am Eingang der Stadt steht der Name: Moskau

- Am Ausgang steht der gleiche Name, aber durchgestrichen: Moskau *



* Ein Beispiel mit Verkehrszeichen, das ich vor langer Zeit in einem Yandex-Artikel gelesen habe, nur erinnere ich mich nicht an den Link. Und ein hervorragendes Beispiel!

Wurzelelement

Jedes XML-Dokument hat ein Stammelement. Dies ist das Tag, mit dem das Dokument beginnt und mit dem es endet. Bei der REST-API ist ein Dokument eine Anforderung, die das System sendet. Oder die Antwort, die sie bekommt.



Um diese Anfrage darzustellen, benötigen wir ein Root-Element. In QuickInfos lautet das Stammelement "req".







Es könnte anders genannt werden:

<main>

<sugg>

Ja, was auch immer. Es zeigt den Anfang und das Ende unserer Anfrage, nichts weiter. Aber im Inneren befindet sich bereits der Hauptteil des Dokuments - die Anfrage selbst. Diese Parameter, die wir an das externe System übergeben. Natürlich werden sie auch in Tags enthalten sein, aber in regulären Tags, nicht in Root-Tags.

Gegenstandswert

Der Wert des Elements wird zwischen den Start- und End-Tags gespeichert. Es kann eine Zahl, eine Zeichenfolge oder sogar verschachtelte Tags sein!



Hier haben wir das Tag "query". Es bezeichnet die Anfrage, die wir an die Tooltips senden.







Inside - der Wert der Anfrage.







Es ist, als hätten wir die Zeile "Victor Ivan" in die GUI (grafische Benutzeroberfläche) gefahren: Der







Benutzer benötigt keine zusätzliche Umreifung, er braucht eine schöne Form. Aber das System muss irgendwie vermittelt werden, dass "der Benutzer genau dies eingegeben hat". Wie zeige ich ihr, wo der übergebene Wert beginnt und endet? Dafür sind Tags da.



Das System sieht das Tag "query" und versteht, dass darin "eine Zeichenfolge enthalten ist, für die Eingabeaufforderungen zurückgegeben werden sollten".







Parameteranzahl = 7Gibt an, wie viele Hinweise in der Antwort zurückgegeben werden sollen. Wenn Sie Tipps in Dadatas Demo-Formular eingeben , werden 7 Tipps an uns zurückgegeben. Dies liegt daran, dass der Wert count = 7 eingenäht ist . Wenn Sie sich jedoch auf die Dokumentation der Methode beziehen, kann die Anzahl zwischen 1 und 20 ausgewählt werden.

Öffnen Sie die Entwicklerkonsole über f12 auf der Registerkarte Netzwerk und sehen Sie, welche Anforderung an den Server gesendet wird. Es wird eine Zählung = 7 geben .







Siehe auch:

Was ein Tester über das Entwicklerfenster wissen muss - Weitere Informationen zur Verwendung der Konsole.

Beachten Sie:

• Victor Ivan - Schnur
• 7 - Nummer

Beide Werte kommen jedoch ohne Anführungszeichen. In XML müssen wir den Zeichenfolgenwert nicht in Anführungszeichen setzen (in JSON müssen wir dies jedoch tun).

Elementattribute

Ein Element kann ein oder mehrere Attribute haben. Wir kennzeichnen sie innerhalb des Abreiß-Tags nach dem Tag-Namen, der durch ein Leerzeichen im Formular getrennt ist

_ = « »

Zum Beispiel:

<query attr1=“value 1”> </query>
<query attr1=“value 1” attr2=“value 2”> </query>

Warum wird das benötigt? Aus den Attributen versteht das System, das die API-Anforderung empfängt, was es überhaupt empfangen hat.



Zum Beispiel führen wir eine Suche im System durch und suchen nach Clients mit dem Namen Oleg. Wir senden eine einfache Anfrage:

<query></query>

Und dafür bekommen wir eine ganze Packung Olegs! Mit unterschiedlichen Geburtsdaten, Telefonnummern und anderen Daten. Angenommen, eines der Suchergebnisse sieht folgendermaßen aus:

<party type="PHYSICAL" sourceSystem="AL" rawId="2">
    <field name=“name"> </field>
    <field name="birthdate">02.01.1980</field>
    <attribute type="PHONE" rawId="AL.2.PH.1">
        <field name="type">MOBILE</field>
        <field name="number">+7 916 1234567</field>
    </attribute>
</party>

Werfen wir einen Blick auf diesen Eintrag. Wir haben das Hauptelement Party .







Es hat 3 Attribute:

• type = «PHYSICAL» — . , : , , . , . ! , , — ,
• sourceSystem = «AL» — . , , .
• rawId = «2» — . , , . , ? sourceSystem + rawId!

Es sind Feldelemente innerhalb der Partei . Feldelemente haben einen Namen Attribut . Der Attributwert ist der Feldname: Name, Geburtsdatum, Typ oder Telefonnummer. So verstehen wir, was unter einem bestimmten Feld verborgen ist . Dies ist aus Support-Sicht praktisch, wenn Sie ein Produkt in einer Box und mehr als 10 Kunden haben. Jeder Kunde hat seine eigenen Felder: Jemand hat eine INN im System, jemand nicht, eine ist wichtig für das Geburtsdatum, eine andere nicht usw. Trotz der unterschiedlichen Modelle verfügen alle Kunden über ein XSD-Schema (das die Anforderung und Antwort beschreibt): - Es gibt ein Party-Element. - es hat Feldelemente;



























- Jedes Feldelement verfügt über ein Namensattribut, in dem der Name des Feldes gespeichert ist.



Die spezifischen Namen der Felder können in XSD jedoch nicht mehr beschrieben werden. Sie sind schon "schau in die TK". Wenn es nur einen Kunden gibt oder Sie Software für sich selbst oder "im Allgemeinen für alle" erstellen, ist es natürlich bequemer, benannte Felder zu verwenden, dh "sprechende" Tags. Was sind die Vorteile dieses Ansatzes:



- Beim Lesen von XSD sind reale Felder sofort sichtbar. TK ist möglicherweise veraltet und der Code ist aktuell.

- Die Anfrage kann einfach manuell in SOAP Ui abgerufen werden - es werden sofort alle erforderlichen Felder erstellt, Sie müssen nur die Werte eingeben. Dies ist praktisch für den Tester + der Kunde testet manchmal so, er ist auch gut.



Im Allgemeinen hat jeder Ansatz ein Existenzrecht. Es ist notwendig, sich das Projekt anzusehen, das für Sie bequemer ist. In meinem Beispiel habe ich nicht sprechende Namen von Elementen - alles wie es sein wirdFeld . Aber an den Attributen kann man schon verstehen, was es ist.



Zusätzlich zu den Feldelementen hat die Partei ein Attribut Element . Verwechseln Sie nicht die XML-Notation und das Geschäftslesen:

• Aus geschäftlicher Sicht ist dies ein Attribut einer Person, daher der Name des Elements - Attribut .
• Aus der Sicht von XML ist es ein Element (kein Attribut!), es wurde einfach Attribut genannt . XML ist es (fast) egal, wie Sie die Elemente benennen, also ist das in Ordnung.

Das Attributelement hat Attribute:

• type = "PHONE" - Attributtyp. Schließlich können sie unterschiedlich sein: Telefon, Adresse, E-Mail ...
• rawId = "AL.2.PH.1" - Kennung im Quellsystem. Es wird für die Aktualisierung benötigt. Schließlich kann ein Client mehrere Telefone haben. Wie kann man verstehen, welches ohne ID aktualisiert wird?

So hat sich das XML herausgestellt. Und vereinfacht. In realen Systemen, in denen Personen gespeichert sind, gibt es viel mehr Daten: etwa 20 Felder der Person selbst, mehrere Adressen, Telefonnummern, E-Mail-Adressen ...



Aber selbst ein riesiges XML zu lesen wird nicht schwierig sein, wenn Sie wissen, wo sich was befindet. Und wenn es formatiert ist, werden verschachtelte Elemente nach rechts verschoben, der Rest befindet sich auf derselben Ebene. Ohne Formatierung wird es schwierig ...



Und alles ist so einfach - wir haben Elemente in Tags eingeschlossen. Innerhalb der Tags befindet sich der Name des Elements. Wenn nach dem Namen etwas steht, das durch ein Leerzeichen getrennt ist: Dies sind die Attribute des Elements.

XML-Prolog

Manchmal sehen Sie oben im XML-Dokument etwas Ähnliches:

<?xml version="1.0" encoding="UTF-8"?>

Diese Zeile wird als XML-Prolog bezeichnet. Es zeigt die im Dokument verwendete XML-Version sowie die Codierung. Der Prolog ist optional, wenn er nicht vorhanden ist - er ist in Ordnung. Wenn dies jedoch der Fall ist, muss dies die erste Zeile des XML-Dokuments sein.



UTF-8 ist die Standardcodierung für XML-Dokumente.

XSD-Schema

XSD ( X ML S chema D efinition) ist Ihre XML-Beschreibung. Wie soll es aussehen, was soll es sein? Dies ist TK in der Sprache der Maschine geschrieben - schließlich schreiben wir das Schema ... Auch im XML-Format! Das Ergebnis ist XML, das ein anderes XML beschreibt.



Der Trick besteht darin, dass die Prüfung gemäß dem Schema an die Maschine delegiert werden kann. Und der Entwickler muss nicht einmal jede Überprüfung planen. Es genügt zu sagen: "Hier ist ein Diagramm, überprüfen Sie es."



Wenn wir eine SOAP-Methode erstellen, geben wir im Schema Folgendes an:

• Welche Felder werden in der Anfrage enthalten sein?
• Welche Felder werden in der Antwort enthalten sein?
• Welche Datentypen hat jedes Feld?
• welche Felder werden benötigt und welche nicht;
• Hat das Feld einen Standardwert und was ist das?
• ob das Feld eine Längenbeschränkung hat;
• Hat das Feld andere Parameter?
• ;
• ...

Wenn nun eine Anfrage bei uns eingeht, wird sie zunächst gemäß dem Schema auf Richtigkeit überprüft. Wenn die Anforderung korrekt ist, starten wir die Methode und erarbeiten die Geschäftslogik. Und es kann komplex und ressourcenintensiv sein! Erstellen Sie beispielsweise eine Stichprobe aus einer Datenbank mit mehreren Millionen Dollar. Oder führen Sie ein Dutzend Überprüfungen an verschiedenen Datenbanktabellen durch ...



Warum also eine komplexe Prozedur ausführen, wenn die Abfrage offensichtlich "schlecht" ist? Und nach 5 Minuten einen Fehler machen, und nicht sofort? Die Schemaüberprüfung hilft dabei, offensichtlich ungültige Anforderungen schnell herauszufiltern, ohne das System zu überlasten.







Darüber hinaus bieten einige Client-Programme einen ähnlichen Schutz für das Senden von Anforderungen. Zum Beispiel kann SOAP Ui Ihre Anfrage nach wohlgeformter XML-Datei überprüfen und sie wird einfach nicht an den Server gesendet, wenn Sie es vermasselt haben. Spart Zeit bei der Datenübertragung, gut gemacht!







Für den einfachen Benutzer Ihrer SOAP-API hilft Ihnen das Schema dabei, zu verstehen, wie eine Anforderung erstellt wird. Was ist ein "einfacher Benutzer"?

1. Der Entwickler des Systems, der Ihre API verwendet, muss in den Code schreiben, was genau von seinem System an Ihr System gesendet werden soll.
2. Ein Tester, der genau diese API überprüfen muss - er muss verstehen, wie die Anforderung gebildet wird.

Ja, ja, idealerweise haben wir eine detaillierte TK, in der alles gut beschrieben ist. Aber leider und ah, das ist nicht immer der Fall. Manchmal existiert die TK einfach nicht und manchmal ist sie veraltet. Das Schema wird jedoch nicht veraltet sein, da es aktualisiert wird, wenn der Code aktualisiert wird. Und es hilft nur zu verstehen, wie die Anfrage aussehen sollte.







Zusammenfassend lässt sich sagen, wie das Schema bei der Entwicklung der SOAP-API verwendet wird:

• Unser Entwickler schreibt ein XSD-Schema für die API-Anforderung: Sie müssen ein Element wie dieses und jenes, das solche und solche untergeordneten Elemente hat, mit solchen und solchen Datentypen übergeben. Diese sind erforderlich, diese nicht.
• Der Entwickler des Kundensystems, das in unser System integriert ist, liest dieses Diagramm und erstellt seine Anforderungen entsprechend.
• Das Kundensystem sendet Anfragen an uns.
• Unser System prüft Anfragen von XSD - wenn etwas nicht stimmt, ist es nur ein Schütteln.
• Wenn die XSD-Anforderung die Überprüfung bestanden hat, aktivieren Sie die Geschäftslogik!

Nun wollen wir sehen, wie die Schaltung aussehen könnte! Nehmen Sie zum Beispiel die doRegister- Methode in Users. Um eine Anfrage zu senden, müssen wir E-Mail, Name und Passwort übergeben. Es gibt unzählige Möglichkeiten, eine Abfrage richtig und falsch zu schreiben:





Versuchen wir, ein Diagramm dafür zu schreiben. Die Anfrage muss 3 Elemente ( E-Mail, Name, Passwort ) vom Typ "Zeichenfolge" (Zeichenfolge) enthalten. Wir schreiben:

<xs:element name="doRegister ">
   <xs:complexType>
   <xs:sequence>
     <xs:element name="email" type="xs:string"/>
     <xs:element name="name" type="xs:string"/>
     <xs:element name="password" type="xs:string"/>
   </xs:sequence>
   </xs:complexType>
</xs:element>

Und in der WSDl des Dienstes ist es noch einfacher geschrieben:

<message name="doRegisterRequest">
   <part name="email" type="xsd:string"/>
   <part name="name" type="xsd:string"/>
   <part name="password" type="xsd:string"/>
</message>

Natürlich kann ein Schema mehr als nur Inline-Elemente enthalten. Dies können Zahlen, Datumsangaben, Boolesche Werte und sogar einige ihrer eigenen Typen sein:

<xsd:complexType name="Test">
   <xsd:sequence>
     <xsd:element name="value"   type="xsd:string"/>
     <xsd:element name="include" type="xsd:boolean" minOccurs="0" default="true"/>
     <xsd:element name="count" type="xsd:int" minOccurs="0" length="20"/>
     <xsd:element name="user" type="USER" minOccurs="0"/>
   </xsd:sequence>
</xsd:complexType>

Sie können auch auf ein anderes Schema in einem Schema verweisen, was das Schreiben von Code erleichtert. Sie können Schemas für verschiedene Aufgaben wiederverwenden.



Siehe auch:

XSD - Smart XML - nützlicher Artikel aus Habr

XSD Schema Definition Language - Es gibt praktische Tabellen mit Werten, die Sie verwenden können.

XSD Schema Description Language (XML-Schema)

Ein Beispiel für ein XML-Schema im Tutorial

Offizielle Website w3.org

Übung: Schreiben Sie Ihre Anfrage

Ok, jetzt wissen wir, wie man eine Anfrage nach einer API-Methode im XML-Format "liest". Aber wie soll man es laut TK erstellen? Lass es uns versuchen. Wir schauen uns die Dokumentation an. Und deshalb gebe ich ein Beispiel von Dadata - es ist eine großartige Dokumentation !







Was ist, wenn ich nur die vollständigen Namen von Frauen zurückgeben möchte, die mit "An" beginnen? Nehmen wir unser ursprüngliches Beispiel:

<req>
  <query> </query>
  <count>7</count>
</req>

Zunächst ändern wir die Anfrage selbst. Jetzt ist es nicht mehr "Victor Ivan", sondern "An":

<req>
  <query></query>
  <count>7</count>
</req>

Als nächstes schauen wir uns die TK an. Wie kann ich nur weibliche Trinkgelder zurückgeben? Es gibt einen speziellen Parameter - Geschlecht . Der Parametername ist der Name der Tags. Und wir haben den Boden schon hineingelegt. "Female" in Englisch ist FEMALE , auch in der Dokumentation. Insgesamt erhalten:

<req>
  <query></query>
  <count>7</count>
  <gender>FEMALE</gender>
</req>

Sie können das Unnötige löschen. Wenn uns die Anzahl der Hinweise egal ist, werfen wir den Parameter count aus. Immerhin ist es laut Dokumentation optional. Erhielt eine Anfrage:

<req>
  <query></query>
  <gender>FEMALE</gender>
</req>

Das ist alles! Wir haben ein Beispiel als Grundlage genommen, einen Wert geändert, einen Parameter hinzugefügt und einen entfernt. Es ist nicht so schwer. Besonders wenn es eine detaillierte Spezifikation und ein Beispiel gibt)))

Versuch es selber!

Schreiben Sie eine Anforderung für die MagicSearch- Methode in Benutzer. Wir wollen alle Iwanows zufällig finden, an denen dringende Aufgaben hängen.

Gut geformtes XML

Es ist Sache des Entwicklers, zu entscheiden, welches XML korrekt ist und welches nicht. Es gibt jedoch allgemeine Regeln, gegen die nicht verstoßen werden kann. XML muss gut geformt, dh syntaktisch korrekt sein.



Um XML auf Syntax zu überprüfen, können Sie einen beliebigen XML-Validator (und Google) verwenden. Ich empfehle die w3schools Seite . Es gibt den Validator selbst + eine Beschreibung typischer Fehler mit Beispielen.



Im fertigen Validator fügen Sie einfach Ihr XML ein (z. B. eine Anfrage für den Server) und prüfen, ob alles in Ordnung ist. Aber Sie können es selbst überprüfen. Gehen Sie die Syntaxregeln durch und prüfen Sie, ob Ihre Abfrage ihnen folgt.



Gut geformte XML-Regeln:

1. Es gibt ein Wurzelelement.
2. Jedes Element hat ein schließendes Tag.
3. Tags unterscheiden zwischen Groß- und Kleinschreibung!
4. Die korrekte Verschachtelung von Elementen wird eingehalten.
5. Attribute werden in Anführungszeichen gesetzt.

Lassen Sie uns jede Regel durchgehen und diskutieren, wie wir sie beim Testen anwenden können. Das heißt, wie man eine Abfrage korrekt "bricht", indem man sie mit einer wohlgeformten XML vergleicht. Warum wird das benötigt? Schauen Sie sich das Feedback des Systems an. Können Sie anhand des Fehlertextes genau verstehen, wo Sie es vermasselt haben?



Siehe auch:

Fehlermeldungen sind ebenfalls Dokumentation, testen Sie sie! - Warum Fehlermeldungen testen?

1. Es gibt ein Wurzelelement

Sie können nicht einfach 2 XML nebeneinander stellen und davon ausgehen, dass "das System selbst herausfindet, dass es sich um zwei Anforderungen handelt, nicht um eine". Wird nicht verstehen. Weil du nicht solltest.



Und wenn Sie mehrere Tags hintereinander ohne ein gemeinsames übergeordnetes Element haben, ist dies eine schlechte XML-Datei, die nicht gut geformt ist. Es sollte immer ein Wurzelelement geben:



Was tun wir, um diesen Zustand zu testen? Richtig, wir entfernen die Root-Tags aus unserer Anfrage!

2. Jedes Element hat ein schließendes Tag

Hier ist alles einfach - wenn ein Tag irgendwo geöffnet wurde, muss es irgendwo geschlossen werden. Willst du brechen? Entfernen Sie das schließende Tag eines Elements.



Aber hier ist es erwähnenswert, dass es einen Tag geben kann. Wenn das Element leer ist, können wir mit einem Tag auskommen, indem wir es am Ende schließen:

<name/>

Dies entspricht der Übergabe eines leeren Werts

<name></name>

Ebenso kann der Server einen leeren Tag-Wert an uns zurückgeben. Sie können versuchen, leere Felder mit der FullUpdateUser- Methode an Benutzer zu senden . Und dies ist in der Anfrage akzeptabel (ich habe das Feld name1 leer gesendet ) und in der SOAP Ui-Antwort werden leere Felder genau für uns gerendert.







Total - Wenn es ein öffnendes Tag gibt, muss es ein schließendes Tag geben. Oder es wird ein Tag mit einem Schrägstrich am Ende sein.



Entfernen Sie zum Testen alle schließenden Tags in der Anforderung.

3. Tags unterscheiden zwischen Groß- und Kleinschreibung

Während sie das erste geschrieben haben, schreiben wir auch das abschließende. GENAU SO! Und nicht so, wie du es wolltest.



Zum Testen ändern wir jedoch das Register eines der Teile. Solches XML ist ungültig

4. Korrigieren Sie die Verschachtelung von Elementen

Elemente können nacheinander verschoben werden







Ein Element kann in einem anderen verschachtelt sein.







Elemente können sich jedoch NICHT überlappen!

5. Attribute sind in Anführungszeichen eingeschlossen

Selbst wenn Sie das Attribut als Zahl betrachten, wird es in Anführungszeichen gesetzt:

<query attr1=“123”> </query>
<query attr1=“” attr2=“123” > </query>

Zu Testzwecken versuchen wir, es ohne Anführungszeichen zu bestehen:

<query attr1=123> </query>

Gesamt

XML (e X Tensible M arkup L Anguage) wird zum Speichern und Übertragen von Daten verwendet.

— API-. SOAP-, . SOAP XML. REST, — XML, JSON.



— XML . , . XML - , , - .



XML open-source folks. , JacksonJsonProvider, «» — , (featuresToEnable), , (featuresToDisable).

Das XML-Format folgt Standards. Eine syntaktisch falsche Anfrage geht nicht einmal an den Server, der Client schneidet sie ab. Erst gut geformt, dann Geschäftslogik.



Gut geformte XML-Regeln:

1. Es gibt ein Wurzelelement.
2. Jedes Element hat ein schließendes Tag.
3. Tags unterscheiden zwischen Groß- und Kleinschreibung!
4. Die korrekte Verschachtelung von Elementen wird eingehalten.
5. Attribute werden in Anführungszeichen gesetzt.

Wenn Sie ein Tester sind, versuchen Sie beim Testen von XML-Abfragen unbedingt, jede Regel zu brechen! Ja, das System sollte in der Lage sein, solche Fehler zu behandeln und eine angemessene Fehlermeldung zurückzugeben. Aber das macht sie nicht immer.



Und wenn das System öffentlich ist und eine leere Antwort auf eine falsche Anfrage zurückgibt, ist das schlecht. Weil der Entwickler eines anderen Systems es in der Anfrage beheben wird und durch die leere Antwort nicht einmal versteht, wo genau. Und es wird die Unterstützung belästigen: "Was ist los mit mir?", Informationen Stück für Stück und in Form von Screenshots des Quellcodes werfen. Brauchst du es? Nein? Stellen Sie dann sicher, dass das System eine eindeutige Fehlermeldung ausgibt!



Siehe auch:



Was ist XML XML

Tutorial

Lernen Sie XML. Eric Ray (XML Book)

Hinweise zu XML und XLST



PS - Weitere hilfreiche Artikel finden Sie in meinem Blog unter dem Tag "nützlich" . Und nützliche Videos sind auf meinem Youtube-Kanal