3 ms·
As always, the devil is in the details. SOAP didn't get complicated for absolutely no reason. As your application grows, you'll need to think about error / exce
by icedchai 4y ago
As always, the devil is in the details. SOAP didn't get complicated for absolutely no reason. As your application grows, you'll need to think about error / exception handling, backwards compatibility (new parameters), and versioning, to start.
- wruza 4y agoThese nuances are not unique to a protocol. The fact that some prior tech wasn’t smart enough to think about these doesn’t mean that someone will inevitably repeat it. “SOAP” is like an elevator anxiety trigger because one of them failed brutally in the past. As you application grows No, you have to design it in from the beginning. How can someone not think of exception borders, API contracts, safety/idempotency and versioning even for a single call? I see that errors are handled well by telefunc. Other issues are easy to do in the same way you do it in REST/POST, i.e. foo(…, new_arg), foo_v2(…), plus some docs. It is literally just a different form with the same content, which is closer to the language and doesn’t require pages of almost identical parametrized wrappers.
- icedchai 4y agoYou’d be surprised how often people fail to consider things like versioning when building APIs. Yes, they absolutely should be considered from the beginning. I’ve been burned in the past by RPC (mainly SOAP), but will take a deeper look and try to keep an open mind. Building “REST” APIs is damn tedious.