So my problem is that REST stuff is usually a horrible mess with lots of special-casing, while SOAP gets ridiculously leaky and requires very tight coupling and lots of tooling to allow servers or clients to implement it cleanly, because the envelope formats etc. are really complex. If you've got something which can consume the WSDL and generate client code then you're good - provided it has a sane connection handler etc. etc. etc. because usually in my experience they then try to do too much for you and are very vague about what that actually is.
Needs something else. Preferably something already invented. My employer has a SOAP API which is very annoying, written in a framework that lets us throw any exception we like back to the clients, thus exposing internal details by accident in an interface which we then can't change because people might be processing those exception names to understand the errors they're getting when their requests aren't valid. This is where the idea of RPC needs a gatekeeper (oh for a framework-level option to say "you can only throw exceptions to the client which are in this namespace" or maybe "only ones which derive from an class in this namespace").
We also have a REST API, which is reasonably good at hitting the RESTful ideas, but not great everywhere because yup, there's that ambiguity in the conceptual framework itself.
There's also a lot of code involved in actually consuming the thing.
I need to read up on alternatives. But our customers aren't going to change any time soon!
Needs something else. Preferably something already invented. My employer has a SOAP API which is very annoying, written in a framework that lets us throw any exception we like back to the clients, thus exposing internal details by accident in an interface which we then can't change because people might be processing those exception names to understand the errors they're getting when their requests aren't valid. This is where the idea of RPC needs a gatekeeper (oh for a framework-level option to say "you can only throw exceptions to the client which are in this namespace" or maybe "only ones which derive from an class in this namespace").
We also have a REST API, which is reasonably good at hitting the RESTful ideas, but not great everywhere because yup, there's that ambiguity in the conceptual framework itself.
There's also a lot of code involved in actually consuming the thing.
I need to read up on alternatives. But our customers aren't going to change any time soon!