I miss JSONRPC, and have no idea why it didn't take off the way REST did. It seems RPC and Lambda would play nicely together.
REST is the new SOAP
281–290 of 351 posts
Re: REST is the new SOAP
#282Earlier quoted context omitted.
What's funny is that most consumers of REST APIs do it through a wrapper that turns it back into a statically typed RPC. REST truly is a useless middleman that no one realizes they just don't need.
I doubt that most consumers of REST APIs are doing anything statically typed. I would guess that the vast majority of REST consumers are written in browser javascript. Server side, I bet at least half are written in a dynamic language.
I don't think the parent here is talking about whether the language is static/dynamic.
The point is that most REST calls are wrapped in a statically 'dispatched' function call.
So in most cases you'd do something like:
let foo = () => http.GET('/foo');
.
.
.
foo() //foo is statically dispatched in the source code hereRe: REST is the new SOAP
#283What are the best options for building JSON RPC client/server in javascript ?
Essentially I am looking at a Node.js based server and Browser based client as of now but cross language compatibility would be nice to have.
gRPC pure javascript client [3] is labelled as "incomplete and experimental".
axon [4] looks interesting but seems to have received no activity in almost a year. I am also slightly skeptical of adopting a tj project given his departure from Node community.
Jayson [1] was the only one I could find in the search results [2] which is actively maintained and well documented.
--
[1] https://github.com/tedeh/jayson
[2] https://npms.io/search?q=rpc
[3] https://github.com/grpc/grpc-node#pure-javascript-client
Re: REST is the new SOAP
#284Why is REST so popular? Because it's easy to implement and works for lots of use cases. I'm sorry that you found places it doesn't, but in the real world, having been through that SOAP pain it's being compared to, I'd say there's not even a comparison. Everyone seems to want to find a reason to dislike product/technology/feature X but in this case, X is just better than anything we've had for a 90% adoption case. Wha…
[deleted]
Re: REST is the new SOAP
#285Well of course comparing state of the art jsonrpc with spaghetti rest will give jsonrpc a headstart
In truth the error is in the premise “we switched rest because everyone’s doing it/is the way webservices are developed now”
Well, no, and that’s the issue with most “rest” api that actually are jsonrpc with html verbs (and ignoring that using json for rest is impossible to begin with): they were written to hit a bullet point on a feature list
Re: REST is the new SOAP
#286Earlier quoted context omitted.
Crafting REST request with JSON payload is significantly easier than doing that with SOAP (or, rest it in peace, CORBA).
That is highly dependent on the language you are using. Many languages support auto generation of consumer and producer code based off of WSDLs. And AFAIK, most languages that don't have the auto gen tools do have XPATH libraries for easily manipulating templated SOAP requests.
It's still much faster to run curl with JSON, than to run auto-gen tool and write a whole test program to call an API.
Re: REST is the new SOAP
#287Earlier quoted context omitted.
Crafting REST request with JSON payload is significantly easier than doing that with SOAP (or, rest it in peace, CORBA).
The author was comparing REST to json-rpc. Nowhere in the article does he propose that people use SOA or CORBA.
There's no difference between debugging REST and JSON-RPC over HTTP, so there's no point to compare them. The other alternatives, that I've mentioned, are less easy to debug.
Re: REST is the new SOAP
#288Indeed. Rest us nice for some cases but quite complex in rules. Especially if you use HATEOAS.
These days I always recommend GRPC over protobuf for inter services communication.
Re: REST is the new SOAP
#289Earlier quoted context omitted.
I doubt that most consumers of REST APIs are doing anything statically typed. I would guess that the vast majority of REST consumers are written in browser javascript. Server side, I bet at least half are written in a dynamic language.
I don't think the parent here is talking about whether the language is static/dynamic. The point is that most REST calls are wrapped in a statically 'dispatched' function call. So in most cases you'd do something like: let foo = () => http.GET('/foo'); . . . foo() //foo is statically dispatched in the source code here
It seems like "RPC" is being used pretty loosely in this thread. Whether foo in your example is RPC or not depends on its signature, if it attempts to synchronously return the response from the server, then it is RPC, if it just returns a Promise then it isn't.
Re: REST is the new SOAP
#290Earlier quoted context omitted.
If you're defining an RPC protocol in just a few minutes, you're leaving a ton of stuff out. Anyone that assumes an RPC call will successfully complete or assumes the network is always there, is writing buggy code. An "RPC protocol" makes writing such buggy code easier. A REST protocol makes it slightly harder. In theory, they are almost identical. But in practice, developers equate RPC calls with function calls, whi…
How is it any different in any way than any other async function? You just end up providing an unusually large number of parameters via headers and body, then at some point in the future the request completes with values and/or errors. What separates them?
Classic RPC functions would never be async, since the idea behind RPC is to replace a sync local function with a sync remote function, without having to make any changes to the calling code.
"Async RPC" is a more recent idea, but still gets referred to as "RPC", so the complaints about classic RPC still get raised since the term is overloaded.