Search code examples
web-servicesrestsoap

Make REST communicate with SOAP

I have two systems, one (let's call it S1) that exposes a RESTful API (let's call it WS1) and another one (let's call it S2) that exposes a SOAP API (let's call it WS2).

I'm trying to figure out a way to get data from S1 and add it into S2. WS1 exposes methods for both adding/getting data (into/from S1) while WS2 only has methods for adding data (into S2).

Can these two web service communicate directly between each other or should there be some kind of mechanism in between. My guess is that "somebody should be managing their discussion".

Solution

  • Where are the clients?

    You have a REST Server and a SOAP Server, both of their goals is to wait for requests from their respective clients -- it doesn't matter if the operations they implement read and/or write their data sets, a client still needs to initiate communication.

    Bridge the gap.

    Because of this you'll need a bridging client to request to read something from the REST Server and request to write something into the SOAP Server. The rest of the infrastructure for the bridge is up to you.

    You can write a light script that pulls RESTful data and pushes SOAP messages for a handful of particular RESTful resources or you can write a general purpose REST2SOAP bridge which can map a RESTful resource to a SOAP message endpoint based on a conversion convention.

    Direct vs. Message Queues.

    Writing an abstract bridge client will allow you to run it by directly calling the REST service, receiving data, processing it, directly calling the SOAP service and sending it the data. If this is a low-load situation that's fine.

    If we have a high load of data to process doing things synchronously will not be feasible, so we introduce message queues.

    The producer:

    • reads data from the REST service;
    • (perhaps) processes it into a local form (which the bridge client understands such as arrays and objects);
    • then serializes it (serialize, json_encode, etc.);
    • puts it on a message queue.

    The consumer(s)

    • listen to the message queue;
    • when it receives a new message it deserializes it;
    • processes it;
    • sends it to the SOAP service.

    The overall advantage of the message queues is the fact that you can start up as many producers or consumers as you need depending on which of these services runs slower.