Introduction to Specaria S2R

Specaria S2R converts SOAP and REST services in both directions within your VPC. It generates deterministic, full-field mappings from existing contracts.

Applies to1.7.6

Introduction to Specaria S2R

Specaria S2R (product ID s2r) is a service that converts between SOAP and REST protocols in both directions. It is designed to run within your own Virtual Private Cloud (VPC), acting as a bridge between legacy SOAP services and modern REST-based consumers, or vice-versa.

The platform generates deterministic, full-field mappings directly from your service contracts (WSDL or OpenAPI), ensuring that every element, attribute, and optional field is accounted for without requiring you to learn a proprietary transformation language. It provides in-app observability and runs alongside your existing API gateway and SOAP services, rather than replacing them.

As of version 1.0, Specaria S2R is at General Availability.

How it Works

Specaria S2R operates on a Publish/Consume model, allowing it to handle both directions of the SOAP-to-REST boundary on the same runtime. The direction of conversion is a configured property of each service.

The Publish/Consume Model

Publish: REST Facade over a SOAP Backend

In the Publish model, Specaria S2R exposes a modern REST/JSON API to consumers while interacting with a legacy SOAP service on the backend.

Use Case: Expose a legacy SOAP estate as a clean REST API for new consumers like mobile apps, partner integrations, or AI agents.

Data Flow:

  1. A REST/JSON consumer makes a request to a generated OpenAPI v3 endpoint hosted by the S2R runtime.
  2. The runtime converts the JSON request into a SOAP message.
  3. The runtime sends the SOAP request to your existing backend SOAP service.
  4. The backend service processes the request and returns a SOAP response.
  5. The runtime converts the SOAP response back into a JSON payload and returns it to the consumer.

Consume: SOAP Facade over a REST Backend

In the Consume model, Specaria S2R presents a SOAP endpoint to legacy clients, while the actual backend service has been migrated to REST.

Use Case: Maintain compatibility for legacy SOAP clients while modernizing backend services to REST.

Data Flow:

  1. A legacy SOAP client sends a SOAP request to a WSDL-defined endpoint hosted by the S2R runtime.
  2. The runtime accepts the SOAP call and converts it into a REST/JSON request.
  3. The runtime sends the REST request to your migrated backend REST service.
  4. The backend service processes the request and returns a JSON response.
  5. The runtime wraps the JSON response in a SOAP envelope and returns it to the SOAP client.

In both directions, the runtime supports SOAP 1.1 and SOAP 1.2. As of v1.0, the runtime automatically detects the SOAP version from the message body and Content-Type header.

Architectural Placement

Specaria S2R is designed to be an internal-only component that sits alongside your existing infrastructure. It does not expose public endpoints directly. Your existing gateway or load balancer continues to manage authentication, rate-limiting, traffic management, and WAF policies, routing relevant traffic to S2R.

The following diagram illustrates where S2R fits within a typical stack:

[ SOAP estate ] → [ Gateway edge: F5 / DataPower / load balancer / generic HTTP feed ]
                          │
                          ▼
                  [ SOAP-2-REST by Specaria ]   (runs in your VPC)
                          │
                          ▼
                    [ REST consumers ]
        (mobile apps, partner integrations, SDK clients, AI agents)

Backend credentials used by S2R to call your services are encrypted at rest and are never logged or returned in plaintext in API responses.

Platform Components

The platform consists of several distinct services that share a single PostgreSQL database for storing configuration and state. This separation ensures that control plane operations, such as onboarding a new service, do not compete for resources with the data plane that handles production traffic.

ComponentRole
Admin API (control plane)Manages WSDL/OpenAPI import, service CRUD, mapping generation, versioning, and publish state.
Runtime (data plane)Handles production calls: converts SOAP↔REST, routes to the backend, and emits metrics and audit events.
WorkerExecutes background jobs: discovery aggregation, learned-example curation, spec generation, and alert evaluation.
Admin UIProvides a no-code operator portal for the onboarding wizard, dashboards, log search, and audit trails.
PostgreSQLStores all metadata, mappings, versions, audit logs, and aggregation tables. Table names are prefixed s2r_.

Target Audience

This documentation is intended for technical operators responsible for deploying and managing the platform:

  • Integration Engineers / Architects: Onboard services, configure backends, tune conversion options, and review generated contracts.
  • Platform-Engineering / SRE Teams: Deploy the stack, monitor dashboards and SLOs, search logs by correlation ID, and respond to events like contract drift.
  • Security / Identity Teams: Configure RBAC and SSO (IAP, Azure AD, SAML, OIDC) and manage credential encryption and data retention policies.

See Also

Tagsguides

All SOAP-to-REST docs