proposal

SOAP & XML

This is a proposal, and the most speculative of the three. It sketches how Akuma could mock legacy SOAP services - XML envelopes over a single endpoint - using the same data models as the JSON styles.

Why bother with SOAP?

SOAP is far from dead: banking, telco, government, healthcare, and countless enterprise integrations still ship it. Teams building against those services have almost no pleasant way to mock them. If Akuma can stand up a believable SOAP endpoint from the same YAML that describes a REST one, it reaches users no JSON-only mock tool can.

How SOAP differs from the engine's assumptions

Proposed shape

A SOAP service maps each operation to the same operation/schema/key engine, but routes by SOAP action and renders an XML response:

soap:
  path: /UserService
  operations:
    GetUser:
      operation: get
      key: guid              # read from the request envelope
      response: { schema: User, format: xml }
    DeleteUser:
      operation: delete
      key: guid
      response: { schema: User, format: xml }

The data models (schemas:) are unchanged - only the routing and the response format differ. That's the whole point: one model, many protocols.

WSDL

Many SOAP clients want a WSDL to generate stubs. A generated, served WSDL describing the declared operations and schema types would make the mock drop-in for those clients. This is a stretch goal, listed here so the design leaves room for it.

Open questions