2

We want to build a rest api layer on top of a soap webservice.

Our current situation is that we have a coldfusion application that talks with the webservice, both running on different servers. The webservice has no rest support which is something we do want. It will also never support such a thing in nearby future. Therfore, to achieve this we need to place the rest layer between the soap webservice and our application.

As we eventually want to move our coldfusion application to a new language we do not want to build the "layer" in coldfusion. Therefor the layer can be written in a more future proof language.

However, what concerns me about this approach is the extra call needed to retrieve data:

Old: client -> soap call -> response New: client -> rest call -> soap call -> response

So my question is:

  • How bad will the extra call be performance-wise?
  • Would it be a good idea to cache some of it?
  • Or is our goal better achievable by a different approach?
0

Adding new component to the system can add both an extra value and a cost. So situation with building the rest layer on top of the soap layer is similar to e.g. building rest layer on top of other rest layer.

Example benefits:
- Easier api / faster development against the rest api (if written correctly, might be opposite as well if coded incorrectly)

Example drawbacks:
- extra maintenance cost of the new component (deployment, harder debugging, code changes needs to be reflected in the middleware)

Example topics to consider:
- authentication process
- common timeouts
- error handling
- reponse time - if your soap service reponds in ms then adding extra layer can be a showstopper when overall request time is expected to be minimal. On the other hand if your soap service response is e.g. 2s and extra layer adds 50ms then it is most probably not a problem.
- proper mapping of soap commands to rest resources (can be tricky and complicate your solution even more)

To sum up, adding extra layer is a common solution. But you need to consider all pros and cons to adjust it to your particular case. Like always.

0

You can solve any computer programming problem with indirection, except too much indirection.

I think I can see your thinking here. You want to move to a new application which will be a client of the web service but you don't want to get any of the old dated ickyness of the web service on your nice new clean application. So you want to protect it by wrapping the old web service in REST.

This idea may be workable but it also may be tragically flawed. It really depends on how the SOAP web service is designed. REST is more than simply a protocol. It's a style of building a protocol. It may be that your SOAP web service is architected in a way that is incompatible with following that faithfully.

This nagging concern wont go away until you have this working no matter what I say so I'll show the best way to get this working. For now, forget that the SOAP web service exists.

Instead design the REST service around what you know the application will actually need. Follow all the best REST principles here and don't support anything that you might need. Only things regularly used today.

Now with that REST design that can support your applications needs ask yourself: can you map to your SOAP web service in a reasonable way? Adapting might be significant work. But if you can do it you'll have a well designed REST interface to support your application.

One of my favorite techniques is let use drive design. I'm applying it here as a way to let you evaluate how feasible this approach is for your case with minimal effort.

Sure performance may take a hit but never guess at how much. Measure how much with the simplest test you can. This approach lets you build that test before you rewrite the whole application.

You can even do a differential performance test that retrieves the same thing as the above REST test directly through SOAP. Now you can see exactly what your added overhead is costing you just by comparing times.

This may seem like a fair bit of work but it's work you would have had to do anyway. By putting it up front it lets you settle the issue before doubt about it seeps into the rest of your design.

To speed testing consider investing time with some client emulating tools that can drive these protocols: Postman, Insomnia, Curl...

  • Thank you so much for thinking along. It sure help. I did not find a lot of information about 'let use drive design' though, but I get the picture. – Bram Jun 11 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.