Skip to content

API validation helpers - A standard error response contract and FluentValidation support in .NET web frameworks

License

Notifications You must be signed in to change notification settings

kachalkov/JE.ApiValidation

This branch is 7 commits ahead of justeat/JE.ApiValidation:master.

Folders and files

NameName
Last commit message
Last commit date

Latest commit

author
Alex K
Jun 22, 2017
3fc8338 · Jun 22, 2017

History

82 Commits
Jul 3, 2015
Jun 22, 2017
Jun 4, 2015
Jun 5, 2015
Mar 30, 2016
Mar 30, 2016
Apr 5, 2016
Jan 22, 2016
Jun 26, 2015
Jul 22, 2015
Jan 22, 2016
Jun 22, 2017
Jun 22, 2017
Jun 4, 2015
Sep 23, 2015
Jun 22, 2017

Repository files navigation

JE.ApiValidation

Build status

Features

Standard error response DTO

  • Clients shouldn't have to parse different response bodies to find out what went wrong.
    • 400 Bad Request will give back response bodies complying with the standard contract.
  • Clients shouldn't have to parse text to figure out what sort of error happened.
    • errors have a unique integer ID, split into ranges to denote error classes

Request validation outside of your application logic

...(in a filter, or interceptor), making your code easier to understand.

Error processing outside of your application logic

... by running _validator.ValidateAndThrow(thingToProcess); - the ValidationException is caught and transformed to the standard error response DTO

Hooks to log errors

Each filter or interceptor has a virtual method to allow you to log a warning in your logging framework of choice.

Motivations

  • API consumers want to be able to handle errors in a standard way
    • anything else is wasted time
      • implementing
      • debugging
      • supporting
      • operating

Development

Please follow the guidelines in CONTRIBUTING.md.

  • CI
  • To build, currently, use Visual Studio. We plan to open-source our build scripts, but haven't yet.

Getting Started

Framework agnostic

Request validation

  1. Define your API contract as normal.
  2. Define a class inheriting from AbstractValidator<TDto>.
  3. Make that class visible to IoC.

-> validation will occur within model-binding, and if the DTO is invalid, a 400 Bad Request will result, with a standard error response, with code 40000.

Response processing rules errors

  1. Define a class inheriting from AbstractValidator<TThingYouWantToApplyRulesTo>.
  2. Make that class visible to IoC, take a dependency on it.
  3. Call _validator.ValidateAndThrow(input); in your controller action or handler or service class, or wherever you need to apply rules.

-> A ValidationException will be thrown and caught & handled by the filter/interceptor, and a 400 Bad Request will result, with a standard error response, with code 45000.

WebApi

See the example in src/JE.ApiValidation.Examples.WebApi, and the tests for that in src/JE.ApiValidation.Examples.Tests.WebApi.

WebApi with StructureMapValidatorFectory

Register all implementations FluentValidation's AbstractValidators. These will then run automatically against any matching classes passed into ControllerActions.

See the example in src/JE.ApiValidation.Examples.WebApi.FluentValidation.StructureMap, and the tests for that in src/JE.ApiValidation.Examples.Tests.WebApi.

OpenRasta

See the example in src/JE.ApiValidation.Examples.OpenRasta, and the tests for that in src/JE.ApiValidation.Examples.Tests.OpenRasta.

About

API validation helpers - A standard error response contract and FluentValidation support in .NET web frameworks

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • C# 97.7%
  • PowerShell 2.3%