RPC or RESTful?

RESTful and RPC (among several other service inter-communication methods). I always found it fascinating how easy it is to use RPC. From the developer point of view, you always know the input, output and even what errors may pop-up without hunting any document. It is all there, whether in a compiled java libraries or the xmls that build the schemas of the API!

RPC is easy, nothing required to integrate with the API except imported library and rightful configuration file. That’s it. But hey, where did I find RPC in the market? well, mostly on legacy products which takes one week meetings at least to add one line of code. That’s the magic, they are stable, used in stable products but when you poke their versions, you are doomed.

Not to forget about the data types you can work with, it is not only Strings, numbers, nulls and Booleans, you can use complex objects such as dates or home-made objects. Cool isn’t it, maybe for supercar-blondie (she is awesome!!) if you change a type, say numeric type as minor as float to double, you will break production. Based on true story done by the master! Ata boy!

RESTful Services

But hey, everyone talks about RESTful services! well, RPC can wrap a HTTP which takes it to the closes touch of REST. Meh, not from the user’s point of view!

RESTful is mostly about URLs and data serialization. The ball your architect must think about and handle it back to the developers!

RESTful makes you restless

It’s beautiful to call the API using a url through Postman or a curl command — a total third parties created by genius folks. What’s dope is when you see a response as json and you can parse it with your two eyes without scratching classes and inheritance.

JSON type handling is not robust and may produce compatibility issues when schema versions change. How do you know if a number, e.g. duration, is integer or a float when it comes to a json. Even worse, when a Date is expected, what format will you put there? Well, that SUCKS! But hey, XML is more verbose but still, it is not popular and hard to read and write, no one want’s XML if they are revolutionary enough to use REST!

Some smart people thought of the flaws of json and created the binary json (BSON, BJSON, BISON, …) But they are all niche and no one will use them (except maybe data serialization). Big companies came and built their own formats such as Google thrift and apache Avro which used for hadoop. But no, the header application/json will not digest that.

JSON is not a deal breaker at all, it is more than enough for most purposes!

parametric path

Now comes the parametric path! well, that’s a client nightmare at some level! If you want the details of a transaction when the ID is given, the call GET http://localhost/cookieStore/app/v1/transaction/23434562 is so informative to the point you don’t need to hunt any doc. yeah!! but what if there are two parameters in the path, what comes first? now you need a doc! darn it!

Parametric path is lame anyway! you don’t want to use it for all your Urls togather with url query parameters or even with body or formData! it will be a spaghetti design with no rule of thumb.

The REST reveals NOTHING without a documentation. I am not talking about a textual boring documentation, I am talking about a real documentation such as OpenApi (standardization of swagger, I know, can you believe that?!) documentation. You cannot figure out the API given a Url like RPC auto-completion!

RESTful is the king, RPC falls short

It is more comprehensive, easy to test and use. The versioning, it is as easy as changing the path. I also think that RESTful is more powerful when it comes to headers, you can play with infinite parameters to fit any need.