HTTP/API Automation, JSON Validation, and Service-Level Testing: Core Concepts and Mental Model

1. The problem: a green HTTP status can still describe a broken release

Browser tests from Chapter 16 exercised a user-facing interface. Service-level tests move below the browser and speak HTTP directly. They are usually faster and easier to isolate, but that speed can create misleading confidence if the test only checks 200 OK. A service can return the wrong JSON shape, the wrong record, stale data, an unexpected correlation identifier, or even a success status for a failed business operation.

The central design rule for this chapter is therefore: transport truth and business truth are separate contracts. Transport truth covers method, URL, status, headers, timeout, TLS/authentication, and parseability. Business truth covers fields, relationships, state transitions, identity, invariants, and cleanup.

2. Read-only preflight before creating server or client state

python --version
python -m robot --version
python -m pip show robotframework-requests requests
# Verify the target is loopback before any mutation:
python -c "from urllib.parse import urlparse; u=urlparse('http://127.0.0.1:8766'); print(u.hostname, u.port)"

This inspection does not create an HTTP session or mutate server data. Record the interpreter, Robot version, RequestsLibrary version, underlying Requests version, exact target URL, expected local port, and current output directory. If the hostname is public or production-like, do not continue with the mandatory lab.

3. Mental model: five state stores, not one “Robot API state”

flowchart TD
A[Robot test] --> B[Domain API resource]
B --> C[RequestsLibrary]
C --> D[Python Requests client/session]
D --> E[HTTP request]
E --> F[Loopback service]
F --> G[Server record state]
F --> H[HTTP response]
H --> I[JSON object]
I --> J[Transport + business assertions]
J --> K[output.xml / log.html]

The arrows are ownership transitions. Robot resolves and executes keywords. The resource gives business names to HTTP operations. RequestsLibrary owns the Robot-to-Python bridge. Python Requests owns the concrete client/session object and TLS/socket behavior. The server owns durable fixture state. The response object is evidence returned to the caller. Robot assertions convert observations into PASS/FAIL. Result files record that execution independently of the live HTTP connection.

4. Terms and boundaries before mutation

5. RequestsLibrary is a transport adapter, not the service contract

RequestsLibrary wraps Python Requests and exposes Robot keywords such as GET, POST, DELETE, Create Session, and Status Should Be. Starting with its 0.9 line, sessionless request keywords are available. A sessionless call is useful when one operation does not need persistent cookies or common headers. A session is useful when many calls intentionally share client configuration.

Do not let a session become hidden test state. Cookies, auth, default headers, retry adapters, TLS verification, and base URL configuration live longer than a single low-level request. Their lifetime must be explicit in the resource/lifecycle design.

6. Status handling: implicit checks are useful, explicit negative contracts are safer

RequestsLibrary request keywords perform an implicit status check by default. That is helpful for a straightforward success path: expected_status=201 makes the transport expectation visible at the call. For a deliberately negative case, use expected_status=any to preserve the response and then assert the exact expected status and error body yourself.

${response}=    GET    ${API_BASE}/items/9999    timeout=3    expected_status=any
Status Should Be    404    ${response}
${body}=    Set Variable    ${response.json()}
${error}=    Get From Dictionary    ${body}    error
Dictionary Should Contain Item    ${error}    code    not-found

The distinction prevents a common false green: “the request failed, so the negative test passed.” A negative test passes only when the intended failure contract is observed.

7. JSON is parsed data, not a formatted string

response.json() returns Python data structures. Use Collections/BuiltIn operations to inspect semantic fields. Do not compare pretty-printed JSON strings when order, whitespace, or unrelated fields are not part of the contract.

${body}=    Set Variable    ${response.json()}
${data}=    Get From Dictionary    ${body}    data
${attributes}=    Get From Dictionary    ${data}    attributes
Dictionary Should Contain Item    ${attributes}    name    alpha
Dictionary Should Contain Item    ${attributes}    kind    demo

Focused assertions produce better diagnostics: the failure names the missing/wrong field rather than reporting a giant serialized-body difference.

8. Evidence and privacy

HTTP logs can disclose more than browser screenshots: Authorization headers, cookies, access tokens, personal fields, account IDs, request bodies, and server diagnostics. The local fixture logs only method, path, and a synthetic correlation ID. The Robot suite uses fake payloads. In production architecture, retain enough evidence to reconstruct the failed contract while redacting secrets and minimizing personal data.

9. Why this matters in DevOps

Service-level Robot tests are strong release gates when they are deterministic: they are cheaper than browser flows, can target business contracts directly, and produce structured result evidence. They are weak gates when they depend on a public API, shared environment data, hidden session cookies, blanket retries, or “status code only” checks. The same suite should be reproducible from a developer machine and CI runner with the same command and isolated fixture state.

Knowledge check

10. Summary and bridge

Service-level Robot automation is a pipeline of owned states: Robot execution, domain resource, HTTP library/client, server record state, response data, assertions, and evidence. Lesson 2 builds that pipeline end to end against a disposable loopback CRUD-like fixture.

References and version anchors

• Robot Framework 7.4.2 User Guide — execution, variables, lifecycle, status, result, and library boundaries.
• RequestsLibrary keyword documentation, RequestsLibrary 0.9.7 on PyPI, and maintainer repository — HTTP keyword signatures, session behavior, status handling, and release status.
• Python Requests documentation and Requests 2.34.2 on PyPI — underlying HTTP client semantics and current transport-library release anchor.