Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
When building robust APIs it it really important with validation and descriptive error messages and status codes.
In this post I am going to show you how you can get rid of duplicated code in your Request Handlers by adding MediatR behaviors to take care of validation for resource existence.
MediatR is an in-process messaging library in .NET that supports requests/responses, commands, queries, events etc. Go check it out if you havenât.
In MediatR there is something called behaviors which allow you to build your own pipeline for requests. I use them for cross cutting concerns such as logging and validation of requests parameters.
Recently when some endpoints were developed for a microservice I struggled with duplicated code in my Request Handlers that was necessary to have in place.
To give you an example lets start with a couple of API endpoints, and also the implementation of the Request Handlers with the duplicated code.
The endpoints in this example are:
PUT /groups/{id}
POST /groups/{id}/users
The controller:
Both endpoints need to verify that the id-parameter actually matches a given group to be able to update a group / add user to a group (in my example Iâm using EF Core as persistence, but you can safely ignore that).
As you can see there is an if-check for group existence in both the handlers.
How should we get rid of this duplication? Wouldnât it be good to use some sort of âvalidationâ here as a pre-step, so that the Request Handlers could look like this?
Thank behaviors for that! Letâs introduce an interface that both the requests: UpdateGroupRequest and AddUserToGroupRequest implement.
Then create a behavior implementation class with generic constraint to the interface defined above so that the behavior only applies to requests implementing the IGroupRequest interface.
And a registration example using Autofac:
Now we can rewrite our Request Handlers without the if statements, but still get the benefit of validation!
Lets imagine we now add a couple of more endpoints:
GET /groups/{id}
POST /groups/{id}/permissions
Add the IGroupRequest interface to your requests and you will get this feature out of the box. Pretty simple! I find this kind of approach really useful. What do you think?
We have to keep in mind that there are both some cons and pros to this approach. What Iâve found out is:
Cons
- Multiple roundtrips if you have a database that you validate the existence against.
- Validation as a separate class which might confuse some of the developers
Pros
- Cleaner code in the actual request handler
- No duplicated code scattered all over all Request Handlers that need to validate an entityâs existence
If you liked this post. You know what to do! đ
MediatR behaviors to validate API Resource existence was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.