EasyRPC. Be proud of your APIs (First Part) đ€đ
Whether you are a front or a back developer, itâs quite likely that you already know about Web APIs. You may be consuming them, providing data with themâŠÂ or both. Web APIs are a key part on most projects, and they have been with us for long time. Their evolution has been quite interesting, passing from complex and intricate architectures that boiled our brains to their current state. Over time, it seems that the development community came to an agreement on how Web APIs should work, and now almost everybody has a sense of what they are and how deal with them. They tend to be âRESTfulâ, that is, stateless, and exchanging JSON messages over the HTTP protocol. Â
Our mission as developersÂ
As developers we always should do things right, but not only right, but better than it.Â
Weâre always should try to do more with less, while trying to keep everything as simple as possible. Weâll talk about programming principles in another post.Â
Thatâs why we shouldnât just adopt everything blindly. There may be a better way to do our stuff, and thatâs what we call continuous improvement.Â
And here is where I wanted to go:Â Â
Current Web APIs are rigid and constricting. Â
They clearly leave room for improvement. A lot. They are outlandish, inappropriate artifacts. They are aliens inside our code.Â
Our Web APIs donât shineÂ
Itâs exactly that. We are introducing an unnecessary layer that essentially forces HTTP to adapt to a programming paradigm it wasnât designed for. Â
Adapt, improveÂ
- Why do we still write suboptimal Web APIs? Â
- Why are we always implementing them in the same way without much criticism? Â
- Arenât you tired of exposing and consuming services through yet another useless layer? Â
- Are you still forcing your API to fit into an outdated set of HTTP verbs that obscure your services? Â
- Why do you use Controllers for that?
Pain points
Calling a Web API is boring and sometimes painful because interfaces tend to be unclear, operations arenât clear enough or they donât fit well into the HTTP way of thinking.
Calling Web APIs often require clients that need to be configured. Regarding the code, the server part is ugly, and the client side is, too.
- You need to figure out how your methods fit with the GET, POST, UPDATE, DELETE methods.
- If itâs GET you will have to plan where in the URL are your parameters. Having to do it on your web layer is inconvenient.
- You will spend too much time having to deal with URL routes a mapping.
- Most methods are just entry points that do nothing but delegating the real actions to a service.
- Testing controllers can be a nightmare.
Services should be called with zero pain.
A new approach. Here we go!
Letâs do things differently. Letâs do things more naturally, fluent and terse.
We need something to fill the gap, to ease the pain, to communicate more elegantly among application boundaries.
What if you just had to call a web API service like you call any other class? What if you could stop creating Controllers to deliver our stuff?
EasyRPC is here to heal your soul. It makes your service work like if it was just another local service of your application.
var result = mathService.Add(1, 3);
Pretty conventional, isnât it? Except for the fact that the service is a remote service.
The client side is beautiful, but the server side is pure goodness.
public class MathService : IMathService { public decimal Add(decimal a, decimal b) { return a + b; } }
Nothing more, nothing less.
EasyRPC = Easy + RPC
EasyRPC lives up to its name. For those wondering, RPC stands for âRemote Procedure Callâ, a technology that enables calling service methods like they were local services.
The interesting thing is that you can just ignore anything you had in-between. As soon as you write a service, itâs ready to be used. Zero boilerplate. No waste.
Application boundaries are way less of a concern because you donât ever have to think in all the extra code that conventional Web APIs require, that always end up having sharp edges across layers.
EasyRPC does all the heavy lifting. It just worksÂź
Benefits
Pay close attention, because using it you will automatically get all of these benefits:
- EasyRPC removes the need to think about URL construction, parameter passing, or choosing which HTTP verbs to use, allowing the developer to focus on business logic.
- It integrates with smoothly with ASP.NET Core authentication framework so that authorization attributes are honored as well as other authentication primitives.
- It has built in documentation similar to Swagger, but with no external dependencies đ
- Filters, that provide cross-cutting support for things like transaction commit/rollback, logging, etc. Very similar to MVC filters.
- Clients are generated at run time based on interfaces, allowing the developer to access services without having to write any HTTP code. This is simply awesome.
- Supports inbound and outbound compression (Gzip, Brotly)
- Can be expanded to support encodings other than JSON to things like MessagePack or ProtoBuf
We believe that this way a coding feels so natural that, once you have created your first service, you wonât want to go back đ
But that will be part of our next post, where we will show you the real working code.
Stay tuned!
Written by: JosĂ© Manuel Nieto, part of Idiwork’s team
This way of working with APIs looks great.