3 ms·

Fashion. Lots of modern development practices is fashion-driven. JSON-RPC sounds too old.

cm2187 4y ago
And I am still struggling about the argument of why SOAP is bad but JSON RPC is good. The xml vs json debate is a tab vs double space debate to me.
- jeltz 4y ago
  I have done a ton of integrations including many SOAP ones and it is because the SOAP standard is way too big, especially if we include XSDs. I have never used a SOAP library which implements the whole spec and it is very common for XSDs generated by one SOAP library to generate incompatible client code if you use another library (e.g. .NET and Java SOAP libraries are not compatible in some edge cases). I have quite often had to manually implement my own bespoke SOAP client (on top of some XML library obviously) due to the popular SOAP libraries not supporting the XSD I got. So SOAP is too big and all or virtually all libraries are more or less broken. I have never personally worked with such a broken mess of a protocol as the SOAP ecosystem. EDIFACT is supposed to be worse but I never worked with it, that was just some of my colleagues. JSON-RPC on the other hand is simple and all libraries I have seen implement it correctly and even if there is no library you can easily handroll everything.
  - magicalhippo 4y ago
    > EDIFACT is supposed to be worse I've worked with all three, and I think SOAP is the worst. EDIFACT is huge, but the structuring of the elements are pretty well defined. I've had to both consume and generate non-trivial EDIFACTs and while it looks quite weird it's easy to do and easy to debug, at least in my experience. Except for trivial stuff, SOAP as always been a nightmare for me. We've tried tooling but there always incompatibilities and workarounds needed in our experience. These days I manually generate the SOAP envelopes for each integration we do, with potentially some processing of the payloads as well. While XML is verbose, with a good XSD that doesn't try to be fancy I find it quite nice to work with. Even the signed XML stuff (XMLDSIG), which while it took some time getting into, turned out to be not hard to implement due to tools and libraries that worked. So XML in itself is nice, it's just SOAP that manages to make it all hard for no good reason. JSON-RPC is easy enough, tons of JSON libraries out there that can be used if you need to hand-roll.
- nsonha 4y ago
  > why SOAP is bad but JSON RPC is good probably tooling, I haven't looked into it but whatever tooling available back in those SOAP days probably had poor UX. These days if there is a will to make either SOAP or JSON-RPC the way, the community could probably make better and more tools. Having said they both look shit to me :)). I guess if we go with the assumption that there will be tools to help with debug etc then the whole appeal of text based protocols disappears and you wonder why use such inefficient transports.
- sanxiyn 4y ago
  Who said SOAP is bad? SOAP is good. bugs.debian.org provides SOAP API, and it just works. I imagine maybe SOAP was bad when libraries and tools were immature.
nsteel 4y ago
What do you think about a rebrand? How about jRPC?
- vbezhenar 4y ago
  There are some conventions that modern infrastructure expects. For example client does the request, some proxy intercepts the request, checks some things, then forwards the request. Another reverse-proxy on the server side again intercepts the request and routes it to the final web server. If one of the proxies receives HTTP 5xx, it might perform few retries. Devops people want to have some meaningful info in the URL, so they can write some security or routing logic. It might be useful for devops people to have not just 400, but many different response codes, like 400, 401, 403, 404 for different situations. They'll make metric out of it and set up an alerts. So if I would design modern RPC, I'd go the following route: 1. Do not make it protocol-agnostic, but rather embrace HTTP. Method+URL should contain routing information (jsonrpc method field). Errors should have a way to map on HTTP response codes. It does not mean that it's impossible to use it over say websocket, you just need to wrap it with HTTP-like structure. 2. Do not bind it to JSON-only. There should be a way to provide request parameters via URL query parameters, via JSON body and via protobuf body. Good server implementation should respect Content-Type and respect Accept HTTP headers. So I can call that method via cur, via some JS code or with optimized protobuf mobile SDK. JSON should be the main target, though, other encodings should be mapped to JSON. 3. Support meta-information, probably using something like JSON Schema or OpenAPI. 4. HTTP Method must be used as a caching and idempotency information. GET responses are cacheable. POST is not idempotent, etc. Actually it might look a little bit like REST. But I just tried to extract the most useful parts out of it and remove useless parts like coding some parameters in URL Path or the whole philosophy about entities and stuff. If you don't want to think about caching and idempotency stuff, you just use POST for your endpoints and that's perfectly fine.

And I am still struggling about the argument of why SOAP is bad but JSON RPC is good. The xml vs json debate is a tab vs double space debate to me.

jeltz 4y ago
I have done a ton of integrations including many SOAP ones and it is because the SOAP standard is way too big, especially if we include XSDs. I have never used a SOAP library which implements the whole spec and it is very common for XSDs generated by one SOAP library to generate incompatible client code if you use another library (e.g. .NET and Java SOAP libraries are not compatible in some edge cases). I have quite often had to manually implement my own bespoke SOAP client (on top of some XML library obviously) due to the popular SOAP libraries not supporting the XSD I got. So SOAP is too big and all or virtually all libraries are more or less broken. I have never personally worked with such a broken mess of a protocol as the SOAP ecosystem. EDIFACT is supposed to be worse but I never worked with it, that was just some of my colleagues. JSON-RPC on the other hand is simple and all libraries I have seen implement it correctly and even if there is no library you can easily handroll everything.
- magicalhippo 4y ago
  > EDIFACT is supposed to be worse I've worked with all three, and I think SOAP is the worst. EDIFACT is huge, but the structuring of the elements are pretty well defined. I've had to both consume and generate non-trivial EDIFACTs and while it looks quite weird it's easy to do and easy to debug, at least in my experience. Except for trivial stuff, SOAP as always been a nightmare for me. We've tried tooling but there always incompatibilities and workarounds needed in our experience. These days I manually generate the SOAP envelopes for each integration we do, with potentially some processing of the payloads as well. While XML is verbose, with a good XSD that doesn't try to be fancy I find it quite nice to work with. Even the signed XML stuff (XMLDSIG), which while it took some time getting into, turned out to be not hard to implement due to tools and libraries that worked. So XML in itself is nice, it's just SOAP that manages to make it all hard for no good reason. JSON-RPC is easy enough, tons of JSON libraries out there that can be used if you need to hand-roll.
nsonha 4y ago
> why SOAP is bad but JSON RPC is good probably tooling, I haven't looked into it but whatever tooling available back in those SOAP days probably had poor UX. These days if there is a will to make either SOAP or JSON-RPC the way, the community could probably make better and more tools. Having said they both look shit to me :)). I guess if we go with the assumption that there will be tools to help with debug etc then the whole appeal of text based protocols disappears and you wonder why use such inefficient transports.
sanxiyn 4y ago
Who said SOAP is bad? SOAP is good. bugs.debian.org provides SOAP API, and it just works. I imagine maybe SOAP was bad when libraries and tools were immature.

nsteel 4y ago

What do you think about a rebrand? How about jRPC?

vbezhenar 4y ago
There are some conventions that modern infrastructure expects. For example client does the request, some proxy intercepts the request, checks some things, then forwards the request. Another reverse-proxy on the server side again intercepts the request and routes it to the final web server. If one of the proxies receives HTTP 5xx, it might perform few retries. Devops people want to have some meaningful info in the URL, so they can write some security or routing logic. It might be useful for devops people to have not just 400, but many different response codes, like 400, 401, 403, 404 for different situations. They'll make metric out of it and set up an alerts. So if I would design modern RPC, I'd go the following route: 1. Do not make it protocol-agnostic, but rather embrace HTTP. Method+URL should contain routing information (jsonrpc method field). Errors should have a way to map on HTTP response codes. It does not mean that it's impossible to use it over say websocket, you just need to wrap it with HTTP-like structure. 2. Do not bind it to JSON-only. There should be a way to provide request parameters via URL query parameters, via JSON body and via protobuf body. Good server implementation should respect Content-Type and respect Accept HTTP headers. So I can call that method via cur, via some JS code or with optimized protobuf mobile SDK. JSON should be the main target, though, other encodings should be mapped to JSON. 3. Support meta-information, probably using something like JSON Schema or OpenAPI. 4. HTTP Method must be used as a caching and idempotency information. GET responses are cacheable. POST is not idempotent, etc. Actually it might look a little bit like REST. But I just tried to extract the most useful parts out of it and remove useless parts like coding some parameters in URL Path or the whole philosophy about entities and stuff. If you don't want to think about caching and idempotency stuff, you just use POST for your endpoints and that's perfectly fine.