Om een contentcontrole assertion in te stellen of een waarde om als variabele te worden opgeslagen te extraheren als onderdeel van uw multi-step API controleregel, dient u te specificeren naar welke waarde we moeten kijken. De volgende opties zijn beschikbaar:

  • Response body als JSON: Kies deze optie als de bodycontent van uw respons JSON-data bevat, en u een bepaald element in de JSON-structuur wilt inspecteren of vastleggen. Specificeer in het propertyveld van de assertion of variabele welk JSON-element we moeten inspecteren.

    Voorbeeld

    Stel dat uw JSON respons de volgende content heeft:

    {
      "access_token":"MjAxNy0xMC0wMlQxMDoxMDoyNy42NDkwOTEzWg==",
      "token_type":"Bearer",
      "expires_in":86400
    }

    Om de waarde van het kenmerk access_token vast te leggen, vult u access_token in als de propertywaarde.

    Nog een JSON-voorbeeld: stel dat uw JSON-data een array bevat van een of meer elementen, in dit geval een array van drie produkten:

    [
      {
        "Name": "Alpha Cygnus IX",
        "Price": 20000,
      },
      {
        "Name": "Norcadia Prime",
        "Price": 25000,
      },
      {
        "Name": "Risa",
        "Price": 37500,
      }
    ]

    Om een kenmerk van een van deze produkten te krijgen, zullen we eerst naar één bepaald element in de array moeten verwijzen door middel van een index. De index van het eerste element in een JSON-array is altijd nul: [0]. Dus, om het kenmerk Price van het eerste produkt in onze array vast te leggen, specificeren we [0].Price.

    Opmerking: als de responsbody niet kan worden geparset als JSON, genereert deze functie een fout.

  • Response body als XML:Als uw respons een XML-document bevat, kies dan deze optie en specificeer een XPath query om te bepalen welk stukje inhoud moet worden geïnspecteerd of vastgelegd.

    Voorbeeld

    Stel dat uw XML-respons de volgende content bevat:

    <AuthInfo>
      <access_token>MjAxNy0xMC0wMlQxMDowOTo1My45MDUxNjEyWg==</access_token>
      <expires_in>86400</expires_in>
      <token_type>Bearer</token_type>
    </AuthInfo>

    Om de innerlijke waarde van de access_token node vast te leggen gebruikt u de XPath query /AuthInfo/access_token/text() als de property value.

    Als de responsbody niet als standalone XML-document kan worden geparset, als de XPath query ongeldig is of geen werkelijke waarde uit het document selecteert, wordt er een fout gegenereerd.

  • Response body als text: Respons body als text: als uw respons content geen JSON of XML (bijvoorbeeld platte tekst, HTML of een eigen formaat) is, kunt u deze optie nog steeds gebruiken om die content te doorzoeken. Standaard bekijken we de volledige inhoud van de respons. Dit werkt prima als je alleen een simpele Contains-bewerking wilt uitvoeren (bijvoorbeeld: de responsbody moet de uitdrukking "Price" bevatten, aan die controle wordt voldaan zolang het woord Price ergens in de content staat). Als u de volledige content voor uw assertion of variabeledefinitie wilt gebruiken, laat u het eigenschappenveld leeg.

    Als u echter content van een zeer specifieke locatie in het document wilt inspecteren of extraheren, hebt u een manier nodig om te definiëren welk deel van de content we daarvoor moeten gebruiken. Hiertoe geeft u een reguliere expressie op in het eigenschappenveld. Gebruikmakend van de mogelijkheden voor het matchen van patronen van reguliere expressies, proberen we de regex te matchen en de eerste match te gebruiken om die waarde uit uw content te halen

    Als de reguliere expressie een zogenaamde capturing-groep bevat (waarmee u een intern patroon binnen in de reguliere expressie kunt definiëren), gebruiken we de eerste match voor die capturing-groep.

    Houd er rekening mee dat deze opties alleen van toepassing zijn op tekstinhoud (hoewel ze ook kunnen worden toegepast op responses die JSON of XML bevatten, aangezien deze nog steeds alleen tekst zijn); zoeken naar binaire inhoud wordt niet ondersteund.

  • Statuscode: deze optie inspecteert de numerieke HTTP-statuscode die deel uitmaakt van elke HTTP-respons. In de meeste gevallen wilt u alleen controleren of de status 200 is (wat OK betekent), of in ieder geval geen fout aangeeft. In feite doen we dit standaard voor u: als u geen statuscode-assertion opgeeft, voeren we automatisch de volgende assertion uit, want 4xx- en 5xx-codes zijn meestal foutcodes:

    Status code Is less than 400

    Als u echter zelf een Statuscode-assertion definieert, zal deze onze standaardcontrole overrulen. Als u bijvoorbeeld het volgende definieert

    Status code Is equal to 200

    zullen we precies die toestand controleren.

    Opmerking: Er is een speciaal geval wanneer u een statuscode assertion toevoegt voor code 301, 302, 303, 307 of 308 (d.w.z. een redirect code). Zie voor meer informatie het gedeelte Omgaan met redirects.

  • Statusomschrijving: Deze optie kijkt naar de tekstuele beschrijving van de HTTP-statuscode (formeel de Reason-Phrase genoemd). Dit kan handig zijn als u het gedrag van bepaalde foutcondities in uw API controleert: misschien wilt u verifiëren dat wanneer u onjuiste invoer invoert in uw API, er een bruikbare statusbeschrijving wordt geretourneerd.

  • Response compleet: Met deze optie wordt altijd een booleaanse waarde geretourneerd die is gerelateerd aan het feit of de HTTP request met succes kon worden voltooid. Het retourneert false als we niet konden vaststellen met welke server er verbinding moest worden gemaakt, als er geen verbinding tot stand kon worden gebracht of als de server niet tijdig met een HTTP-respons reageerde. In alle andere gevallen wordt true geretourneerd.

    In de meeste gevallen hoeft u deze optie niet te specificeren, omdat we dit automatisch voor u controleren: op basis van dit assertiontype zullen we een fout melden wanneer we geen HTTP-respons van uw server kunnen ophalen:

    Response completed Is equal to true

    Voor sommige speciale gevallen is het mogelijk om deze controle om te draaien: als u in plaats daarvan false opgeeft, controleren we of het verkrijgen van een succesvolle respons NIET mogelijk is. Dit kan handig zijn als u een webapplicatie of API hebt die alleen binnen uw netwerk beschikbaar moet zijn, ook al is de bijbehorende domeinnaam openbaar beschikbaar. Met behulp van deze controle controleren we of we uw API of web-app niet kunnen bereiken.

  • Response header: Met deze optie kunt u een specifieke HTTP responsheader controleren. U moet de naam van die header opgeven in het eigenschappenveld.

  • Cookie: Met deze optie wordt de huidige waarde van een cookie geretourneerd. U moet de naam van die cookie opgeven in het eigenschappenveld. Houd er rekening mee dat cookies die door uw server worden geretourneerd, behandeld worden als sessiecookies: cookiewaarden worden bewaard, bijgewerkt en teruggestuurd naar uw server tijdens de uitvoering van het volledige scenario, tot de laatste stap. Nadien worden alle cookies verwijderd, ongeacht eventuele richtlijnen voor het vervallen van de geldigheid. Dit betekent dat permanente cookies in essentie worden behandeld als sessiecookies.

  • Content length: Deze optie retourneert de grootte (in bytes) van de responsbody. Houd er rekening mee dat dit de werkelijke lengte van de inhoud is nadat de responsbody is uitgepakt (als uw server deze eerder heeft gecomprimeerd).

  • Duration: Deze optie retourneert de totale hoeveelheid tijd (in milliseconden) die nodig was om de request uit te voeren en de response te ontvangen. Hiermee kunt u de prestaties bijhouden voor afzonderlijke stappen.

Deze optie retourneert de totale hoeveelheid tijd (in milliseconden) die nodig was om de request uit te voeren en de response te ontvangen. Hiermee kunt u de prestaties bijhouden voor afzonderlijke stappen.