3 ms·

Only if you have a screw in the wrong place. We program things to make our jobs easier. If it looks like a call, takes args like a call and returns values like

by wruza 4y ago

Only if you have a screw in the wrong place. We program things to make our jobs easier. If it looks like a call, takes args like a call and returns values like a call, it probably is a call. If you have nothing against a call, you have nothing against RPC. Give me TCP, SMTP-over-SOAP-over-HTTP, XML-over-PigeonPost, whatever. I’ll hide this nonsense in an rpc.<langname> file and turn it into a call, because calls are my main programming instrument. Everything else is just an annoying noise that either takes a page to perform or gets wrapped into the exact same parametrized call.

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 ago
  These 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 ago
    You’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.

by wruza 4y ago

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 ago
These 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 ago
  You’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.