Introduction to Specaria S2R

Specaria S2R (SOAP-2-REST) is a service that converts between SOAP and REST protocols in both directions. It runs entirely inside your own Virtual Private Cloud (VPC), alongside your existing API gateway and backend services. It is designed to bridge legacy SOAP-based systems with modern REST/JSON-based API consumers.

The platform generates a deterministic, full-field mapping for each service directly from its contract (WSDL or OpenAPI). This process covers every element, attribute, and optional field automatically, without requiring you to learn a proprietary transformation language or write per-service scripts. For cases that require custom business logic, mappings can be overridden on a field-by-field basis through the Admin UI. All mappings are versioned and immutable, allowing for one-click rollbacks.

The product is at General Availability (GA) as of version 1.0.

Core Capabilities

Specaria S2R can perform conversions in two directions on the same runtime. The direction is configured on a per-service basis.

Publish: REST Facade over a SOAP Backend

This mode exposes a legacy SOAP service as a modern REST/JSON API.

• Flow: A REST consumer calls an OpenAPI v3-based endpoint generated by S2R. The runtime transforms the incoming JSON request into a SOAP envelope, calls the existing SOAP backend, and transforms the SOAP response back into a JSON payload for the consumer.
• Inbound Contract: OpenAPI v3 (generated per service).
• Backend: Your existing SOAP service.
• Use Case: Modernize access to a legacy SOAP estate for new consumers like mobile apps, partner integrations, or SDKs.

Consume: SOAP Facade over a REST Backend

This mode allows a legacy SOAP client to communicate with a modernized REST backend.

• Flow: A SOAP client sends a request to an S2R endpoint. The runtime transforms the incoming SOAP message into a REST request, calls the migrated REST backend, and wraps the JSON response in a SOAP envelope to send back to the client.
• Inbound Contract: WSDL (served by the S2R consume endpoint).
• Backend: Your migrated REST service.
• Use Case: Maintain compatibility with legacy SOAP clients while modernizing backend services to REST.

The platform supports both SOAP 1.1 and SOAP 1.2, with full XSD coverage. The runtime automatically detects the SOAP version from the message body and Content-Type header.

Architecture

Placement in the Stack

Specaria S2R is designed to integrate with your existing infrastructure, not replace it. Your API gateway continues to handle responsibilities like authentication, rate-limiting, and web application firewall (WAF) duties. S2R sits alongside your gateway and backend services. It can listen to gateway-edge traffic for service discovery and handles the protocol conversion for production traffic.

The following diagram illustrates the typical request flow for the "Publish" use case, where a REST consumer accesses a SOAP backend through S2R.

flowchart TD
    subgraph "API Consumers"
        Consumer["REST Consumer"]
    end

    subgraph "Your VPC"
        Gateway["Gateway / Load Balancer"]
        S2R["Specaria S2R"]
        Backend["SOAP Backend Service"]
    end

    Consumer -- REST Request --> Gateway
    Gateway -- Proxies Request --> S2R
    S2R -- SOAP Request --> Backend
    Backend -- SOAP Response --> S2R
    S2R -- REST Response --> Gateway
    Gateway -- Proxies Response --> Consumer

Platform Components

The platform consists of several distinct services that share a single PostgreSQL database for configuration and state. The control plane (for management) and data plane (for traffic) are separate to ensure that operator activity does not impact production API performance.

The following diagram shows how these components interact.

flowchart TD
    subgraph "Operators"
        Operator["Platform Engineer /<br/>Integration Architect"]
    end

    subgraph "Specaria S2R Platform"
        UI["Admin UI"]
        Admin["Admin API (Control Plane)"]
        Runtime["Runtime (Data Plane)"]
        Worker["Worker (Background Jobs)"]
        DB[(PostgreSQL Database)]
    end

    subgraph "External Systems"
        Consumer["API Consumer Traffic"]
        Backend["Backend Service"]
    end

    Operator --> UI
    UI --> Admin
    Admin --> DB
    Worker --> DB

    Consumer --> Runtime
    Runtime --> Backend
    Runtime --> DB
    Backend --> Runtime
    Runtime --> Consumer

Target Audience

This documentation is intended for the technical teams responsible for operating 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 contract drift.
• Security / Identity Teams: Configure Role-Based Access Control (RBAC) and Single Sign-On (SSO) integrations (IAP, Azure AD, SAML, OIDC), and manage credential encryption and data retention policies.

See Also

• Core Concepts: A glossary of terms used throughout the product UI and documentation.
• Quickstart: A guide to get a service published and running in minutes.
• System Requirements: A checklist to ensure your host environment is compatible.
• The onboarding guide, for instructions on setting up services in both Publish and Consume directions.
• The security guide on Network and Data Residency.

All SOAP-to-REST docs