REST vs. GraphQL – A search for evidence on which is better

Re:REST vs. GraphQL – A search for evidence on which is better by mirekrusin on Wednesday December 16, 2020 @02:14AM (#25439915)

We use jsonrpc over ws on f/e-b/e and between b/e-b/e services in trading system, typescript types for api, runtime type assertion combinator library for io boundary type checks, backend teams co-maintain client libraries to access the service, it works very fast, it is safe and easy to maintain/track changes etc.

[ Parent | on HN ]

Re:REST vs. GraphQL – A search for evidence on which is better by FriedrichN on Wednesday December 16, 2020 @06:36AM (#25441426)

JSON-RPC is my protocol of choice as well. I feel most of these other protocols are mostly an exercise in information exchange theory which make them too idealistic, resulting in poor implementations that do not follow the standard or are extended in non-conforming ways.

In the end you simply want to interact with the client or server and procedure calls do just that. I honestly do not see the use in over complicating that.

[ Parent | on HN ]

Re:REST vs. GraphQL – A search for evidence on which is better by reidrac on Wednesday December 16, 2020 @02:45AM (#25440075)

I've used jsonsprc a few times and my experience was excellent (opposite to GraphQL, actually).

But the jsonrpc endpoint had good documentation and the client library didn't feel alien to the project, like a big query string embedded in the client code.

I wonder why jsonrpc is not used more often; but I guess compared to a REST API, the client may be more complicated.

[ Parent | on HN ]