Skip to Content
E2E Test AutomationFunctional TestingAPI CollectionMock ServersREST and SOAP Mock Requests

1) What ATA Mock Servers Are

ATA Mock Servers let you simulate REST and SOAP APIs without needing the real backend. Teams can:

  • Define endpoints with different request/response mappings.
  • Create multiple mock scenarios for a single endpoint (simulate variants, error codes, edge cases).
  • Mock using JSON (REST) or XML (SOAP).
  • Configure request bodies, responses, query params, XPath rules, and status codes.
  • Quickly prototype, test client apps, and validate integrations.

2) Quick Start

  1. Go to ata.dev and log in.
  2. Navigate to Mock Servers → New Mock Server.
  3. Choose Protocol: REST or SOAP.
  4. Define the endpoint and add Mock Scenarios.
  5. For REST: configure request body, response body, query params.
  6. For SOAP: configure Request Level or XPath Level scenarios with XML.
  7. Save and start the mock server → test from Postman, curl, or your client app.

3) Core Concepts

  • Mock Server: A virtual server hosting mock APIs.
  • Mock Scenario: A mapping of request → response (with variations). Multiple scenarios can exist for the same endpoint.
  • REST Mock: JSON request/response with optional query params.
  • SOAP Mock: XML request/response; supports request‑level or XPath‑level configuration.
  • Supported Methods: REST (all), SOAP (only GET and POST).

4) Mock Servers by Type

4.1 REST Mock Servers

  • Request body (JSON) — define expected input.
  • Response body (JSON) — define what to return.
  • Query params — simulate different responses for different query params.
  • Multiple scenarios — each scenario can define different request/response pairs for the same endpoint.

Example REST Mock Scenario

// Request body
{
  "userId": "123"
}
 
// Response body
{
  "name": "John Doe",
  "status": "active"
}
 
// Query param: ?verbose=true
{
  "name": "John Doe",
  "status": "active",
  "details": { "email": "john@example.com" }
}

4.2 SOAP Mock Servers

Supports GET and POST only.

Types of SOAP mock scenarios:

  1. Request Level 
    <!-- Request -->
<Envelope>
  <Body>
    <GetUser>
      <UserId>123</UserId>
    </GetUser>
  </Body>
</Envelope>
 
<!-- Response -->
<Envelope>
  <Body>
    <GetUserResponse>
      <Name>John Doe</Name>
      <Status>Active</Status>
    </GetUserResponse>
  </Body>
</Envelope>
    • Works on full XML request/response.
    • Example: same request body → different response body/status code.
  2. XPath LevelExample (XPath Value) 
    <Envelope>
  <Body>
    <GetUserResponse>
      <Name>John Doe</Name>
      <Status>Active</Status>
    </GetUserResponse>
  </Body>
</Envelope>
    • Rule: //UserId = 123
    • Response:
    • Allows conditional mocking based on XPath expressions.
    • Two types:
      • XPath Exists → return response if element exists.
      • XPath Value → return response if element value matches.

5) Mock Scenarios in Detail

Each mock scenario defines:

  • Request matcher:
    • REST → request body (JSON), query params.
    • SOAP → request body (XML), or XPath rules.
  • Response definition:
    • Response body (JSON/XML).
    • Status code (200, 400, 500 etc.).
    • Optional headers.
  • Variants:
    • Create multiple scenarios for the same endpoint to simulate success, error, timeout, or custom flows.

6) Workflow Examples

6.1 REST Example

  • Endpoint: POST /users
  • Scenario 1 → request { "userId": "123" } → response 200 { "status": "active" }
  • Scenario 2 → request { "userId": "999" } → response 404 { "error": "Not Found" }

6.2 SOAP Example

  • Endpoint: POST /soap/users
  • Scenario 1 (Request Level): match full request body for <UserId>123</UserId> → return 200 OK XML.
  • Scenario 2 (XPath Value): //UserId[text()='404'] → return 404 Not Found XML response.

7) Best Practices

  • For REST, keep request/response schemas consistent with your real API.
  • Use query params to model different filters/states.
  • For SOAP, prefer XPath Value rules for precise matching.
  • Limit scenarios to realistic cases (success, common error codes, edge cases).
  • Document each scenario (purpose, when to use) for collaboration.

8) Troubleshooting

  • Scenario not matching: Check request body/params vs scenario definition.
  • SOAP mock not triggering: Ensure method is GET or POST only.
  • XPath not working: Validate syntax and that XML namespaces are handled correctly.
  • Multiple matches: The first matching scenario wins → order scenarios carefully.

9) FAQs

Q: Can I create multiple scenarios for the same endpoint? A: Yes, unlimited. Each defines different request/response pairs.

Q: Does ATA support PUT/DELETE for SOAP mocks? A: No, only GET and POST.

Q: What format do I use for REST vs SOAP? A: REST → JSON, SOAP → XML.

Q: Can I return different status codes? A: Yes, configure per scenario (e.g., 200, 400, 500).

Q: Which takes priority if multiple SOAP rules match? A: Scenarios are checked in order; the first match wins.

ATA Mock Servers let you quickly spin up simulated REST and SOAP endpoints with full control over request matching and responses. Perfect for prototyping, testing, and collaboration without relying on live backends.

Mock ServersMonitoring