36 ms·

Eventually you'll reinvent SOAP and be in for a world of pain and suffering with slightly incompatible or overly complex tooling.

guggle 4y ago
And here I am, enjoying JSON-RPC services since 2005, having none of the SOAP or ReST problems.
- icedchai 4y ago
  I will admit that RPC does feel more natural for many applications. In the old days, I worked on an app that used XML-RPC and it was fine. If you can avoid the complex tooling and it works for you / your team, great!
- nixpulvis 4y ago
  It's true however, RPC in it's simplicity loses a lot of the niceties of HTTP and REST. You have no conventions to go off of for state control, no standard for error handling, etc. Maybe you want something more barebones, maybe you want to leverage existing protocols. These days, it's kinda the wild west out there in terms of web standards it seems, so go nuts I guess.
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.

guggle 4y ago

And here I am, enjoying JSON-RPC services since 2005, having none of the SOAP or ReST problems.

icedchai 4y ago
I will admit that RPC does feel more natural for many applications. In the old days, I worked on an app that used XML-RPC and it was fine. If you can avoid the complex tooling and it works for you / your team, great!
nixpulvis 4y ago
It's true however, RPC in it's simplicity loses a lot of the niceties of HTTP and REST. You have no conventions to go off of for state control, no standard for error handling, etc. Maybe you want something more barebones, maybe you want to leverage existing protocols. These days, it's kinda the wild west out there in terms of web standards it seems, so go nuts I guess.

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.