The Tech Corner: Is There a Good Reason to Use JSON-RPC?
By Cesar Delsolar / August 10, 2015
The Tech Corner is a series that explores some of the popular technology used in the business Dashboard world. Topics can vary from data formatting, to algorithms. With these articles, we hope to share our point of view on the cutting edge tech used in the industry. Enjoy!
REST over JSON-RPC
Nowadays it seems like everyone is suggesting to use REST instead of JSON-RPC for your API. This thread on StackOverflow has 22 upvotes for a pro-REST argument and almost no representation for JSON-RPC:
http://stackoverflow.com/quest...
There are many good points there, but I feel there is something missing. About a year ago, I was rewriting my side project web app, in such a way as to keep best practices, and I kept struggling with the types of RESTful endpoints to use for the game API. The app is a simple one – it is a game in which a player races against the clock to solve a set of scrambled words, and at the end the player can see how other players did; there is no interactive multiplayer yet although I hope to add one someday.
Many of the commands are things like a word guess, saving your progress on a word list, giving up and showing solutions. The proper way to implement this to begin with is probably mostly on the client side, and have the server just send a list of words, but since this had begun as a traditional desktop client-server app it was hard for me to let go of that model in my head, plus I had a misguided notion that I needed to make it harder to cheat at the game by manipulating the POST data.
A place for JSON-RPC?
One advantage of using a dumb client/smart server model like I did though is that it makes writing a multiplayer game simpler, as the server can then keep track of the state, and that was at heart what I wanted originally. Nowadays though there is so much cool client-side technology like Firebase that the role of an actual server in this kind of app would be pretty minimal, but that’s another story. Rewriting the app now in the end would probably make heavy use of something like Firebase and/or move most of the logic to the client.
So, while I was struggling to come up with RESTful endpoints that did things such as handle a guess, handle time running out, etc. (what kind of resource is that? The CRUD model doesn’t seem to apply here — and yes, I know CRUD and REST are not the same thing), I thought that there must be a way for me to call these functions remotely that actually seems to make sense and adheres to best practices. I am somewhat familiar with JSON-RPC but have always been annoyed at having to deal with APIs that use it while working at AppInsights because they’re slightly harder to test with tools such as curl, python-requests, etc.. but there is a use for JSON-RPC. A word guess would just be an RPC call to a guess function on my backend, which seems like the cleanest approach. Maybe setting options such as configuration can remain RESTful. While I don’t currently have much time for this app, I will explore the idea in the future for similar apps/services.
An argument for simplicity
Basically, a RESTful app should concern itself mainly with the manipulation of resources. Our future Widget API will use REST to manipulate resources such as widgets, streams, and fields such as their widget titles, and limits, for example. At the same time, JSON-RPC can be used to perform tasks and actions that don’t require an immediate response. For example, we can use it in the future to queue up a new Twitter search, to duplicate a user’s business dashboards, and other asynchronous tasks. The JSON-RPC API can be used internally by our web clients (and future mobile/etc clients) and not necessarily exposed to the user. Maintaining two different APIs should not be such a big deal especially since JSON-RPC is still a very simple protocol.
What do you think of JSON-RPC vs REST?
