Very good post, thank You so much.
What is your opinion about JsonRPC?
I've used recently and is quite easy to build both server and client in any language; moreover it is easily debuggable and it supports multi response and batch operations in order to avoid REST sub-calls.
I know that some inner services in Google/Docker use this approach and in fact is quite resilient to both microservices communication and frontend usage (I know that are a lot of better options).
Bye
Hi! Thanks for the appreciation.
I had totally forgot about Json-RPC mostly because I think I've only seen it once quite some time ago. Beyond being lighter than SOAP, I don't think much of it, mostly because it feels like SOAP on JSON but without service definition. I know there's an evolution of it, JSON-WSP that's trying to address that shortcoming, but I've never seen it in practice.
We're using JSON-RPC 2.0 in our current project. It looks much more meaningful than REST and better separated from underlying transport. For example, it standartizes request and response format, including "anti-caching"/indempotent request measures and error reporting (no need to fiddle with HTTP error codes which are not intended for this purpose). Beside that it has support for some conveniences like positional parameters (allows reduce request size by omitting field names) and batch request/response. Overall I like how it behaves in real life, although tooling is sparce.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very good post, thank You so much.
What is your opinion about JsonRPC?
I've used recently and is quite easy to build both server and client in any language; moreover it is easily debuggable and it supports multi response and batch operations in order to avoid REST sub-calls.
I know that some inner services in Google/Docker use this approach and in fact is quite resilient to both microservices communication and frontend usage (I know that are a lot of better options).
Bye
Hi! Thanks for the appreciation.
I had totally forgot about Json-RPC mostly because I think I've only seen it once quite some time ago. Beyond being lighter than SOAP, I don't think much of it, mostly because it feels like SOAP on JSON but without service definition. I know there's an evolution of it, JSON-WSP that's trying to address that shortcoming, but I've never seen it in practice.
We're using JSON-RPC 2.0 in our current project. It looks much more meaningful than REST and better separated from underlying transport. For example, it standartizes request and response format, including "anti-caching"/indempotent request measures and error reporting (no need to fiddle with HTTP error codes which are not intended for this purpose). Beside that it has support for some conveniences like positional parameters (allows reduce request size by omitting field names) and batch request/response. Overall I like how it behaves in real life, although tooling is sparce.