Are SOAP services better than RESTful services for interfacing with complex scientific models?

Question

I have a scientific model that is typically run by providing it a complex text-based input file. I would like to provide a service endpoint to allow users to instantiate the underlying model. The simplest thing I could do would be to create a RESTful service that lets a user POST the text-based input file to the service. However, if I wanted to hide that input file format from the end user and design an API instead, would it be better to use REST or SOAP? To make this question more concrete, allow me to provide an example of the type of complexity I'm talking about with the input file.

• For a given model run, the user needs to provide one or more "sensors".
• Each "sensor" could be treated as a data type that requires a latitude (float), longitude(float), sensor type (enum).

Using SOAP, I can define an XSD schema that defines:

• a "sensor" type as requiring a latitude (float), longitude (float), and sensor type.
• a "sensor_type" data type that is an ENUM with the appropriate strings as options.
• a "sensor_list" type that mandates 1 or more "sensor" types be provided.

In my eyes, this schema represents a nice way of defining this complexity and guiding the user on how to make a successful request using the subsequent WSDL.

On the other hand, while I am no RESTful web service design expert, it seems like it may be more difficult to properly express this level of complexity. Am I wrong? SOAP services have certainly fallen out of mainstream usage in favor of RESTful services, but I'm wondering whether a SOAP service still makes more sense for use cases like the one I have laid out, or whether I am mistaken and need to learn more about the possibilities with RESTful API design.

Answer 1

I honestly think you could do either and have it work just fine. There are a ton of posts throughout the internet on REST vs. SOAP so I won't reiterate that here. But I want to show that you could use either.

First, representing a sensor. Either REST or SOAP can represent such a thing. For example, anything you want to represent in XML can be done in JSON. EX (XML):

<sensors>
  <sensor>
    <type>your_type</type>
    <longitude>your_longitude</longitude>
    <latitude>your_latitude</latitude>
  </sensor>
  <sensor>
    <type>your_type</type>
    <longitude>your_longitude</longitude>
    <latitude>your_latitude</latitude>
  </sensor>
  ...
</sensors>

Or (JSON):

{
  "sensors": [
    { "type": "your_type", "latitude": "your_latitude", "longitude": "your_longitude" },
    { "type": "your_type", "latitude": "your_latitude", "longitude": "your_longitude" },
    ...
  ]
}

Then you would send that data to an endpoint. In XML it would ultimately be a POST to an endpoint and method (say "/MySOAPService.wsdl?method=CreateSensor" or whatever it would be, forgive my rustiness on SOAP). In REST it would probably be a POST to a method like "/Sensors". Updating in SOAP would be "/MySOAPService.wsdl?method=UpdateSensor" with the sensor ID encoded in the XML. REST would look more like "/Sensors/your_id" with a PUT request (the JSON structure would remain the same in both the create and update method).

Either way, you can make it work. My usual preference is just whatever is easier in my language and what will be easiest for consumers to use.

Answer 2

I think first it's important to clarify some terminology because in this case, a lot of the terms you are using are overloaded in a number of ways. This can lead to a great amount of confusion.

Specifically here, you seem to be referring to the SOAP message format but you are comparing it to REST which is a standard way to interact with the server. And lets be clear, there's very little in SOAP that is used today. You basically get the envelope, the body and the fault types. Do these three XML elements matter? I would argue no. Really you are saying REST versus XML, which doesn't really make sense. Perhaps you mean XML versus JSON, which is a meaningful question.

So first of all, you can absolutely 100% use XML in a RESTful design. In fact you can support XML, SOAP, JSON, Avro, YAML, etc. in a single endpoint with REST. You use media types to accomplish this. In real terms, you can only use SOAP if you are going with SOAP/WSDL.

Now if the question is whether XML is better than JSON, I would say no, unless you want to author documents. The reason XML is better for that is that it allows mixed content in nodes. That is, you can have a some text, another element (e.g. ) some text in that element, and then some more text. But for straight data, JSON is generally better because it's less complicated. If you want a schema, you can do that too. There are also lots of other formats you might want to consider as listed above.

As far as the interactions with the server go, REST is far superior. You can actually do everything with a REST server that you can do with the old-style SOAP/WSDL servers as long as you don't mind doing things 'wrong' from a RESTful perspective. That is, if you want to do everything with POST even though it's the wrong method per the HTTP specs, you can do that. There's really nothing magical about SOAP/WSDL, it's only advantage I see is that the tooling is more mature but even that doesn't pan out that well.

Answer 3

As you already know, SOAP/WSDL was historically used to generate proxy classes that you could easily hook up to any application for consumption.

It's worth noting that proxy classes like this are not required by Javascript; since Javascript recognizes JSON natively, it will automatically create dynamic objects from the JSON; you simply consume the resulting object, directly.

Similarly, parsers like Newtonsoft.Json do not require schemas to work properly. You can either consume a dynamic variable and bind its members at runtime, or provide the consumer with matching proxy classes (i.e. DTO's).

In any case, if you need the equivalent of WSDL in JSON, consider JSON Schema. Clients can use tools like NJsonSchema to generate proxy classes.

Answer 4

As the other answers suggest, you can mostly do the same things with SOAP/XML and REST/JSON.

But I wanted to add that in modern languages and frameworks REST/JSON is way easier to implement (as a service provider) and to consume.

So ask your consumers what they would like to have, but if you can't, I'd assume that REST is easier for them.

Answer 5

I found REST a more modern and flexible architecture/approach than SOAP. It is easier to understand, use, extend and maintain.

Some advantages of REST:

• Simple to test/debug, by using HTTP requests with a tool like Postman
• REST operates with data mainly in JSON format, easier to manage, SOAP is XML based.
• It allow partial implementation, just needed functions/routines. Using SOAP in most programming languages you should to import whole WSDL. It is "static" and does not support late binding.
• The same URI in REST can serve all basic data management operations: select/insert/update/delete
• I meet cases when some SOAP libraries/clients does not pack the data exactly according to SOAP standard/specifications, and there was some incompatibilities between two systems, needed to be integrated.

Answer 6

OK so, XML IS superior to JSON in that it you can define a complex schema which both act as documentation and validation of the datastructure.

In addition the actual JSON spec, coming from javascript is somewhat light on data types. eg it only has 'number' rather than int, float, decimal etc. If you have large numbers you might want to use a format which can communicate this.

However there is a third option, which is just sticking with the 'typical' file format. If this is well documented and already in use. Then it might be easiest for everyone if you just accepted a post variable data: with the 64 bit encoded file data