007 End Point Filters
here the question is do you think that the filters work with minimal API end points the answer is no the regular filters that we have learned in the previous sections such as authentication filters action filters result filters all of these doesn't work with end points of minimal API but what if you would like to write some before logic and after Logic for the end points of minimal API exactly for this question the answer is endpoint filters they work almost equivalent to action filters that is they contain the before logic as well as after Logic the before logic executes before the endpoint execution that is mainly used to perform the validation and the after logic of the endpoint filter execute after the execution of the end point generally we keep the code for validation of parameters in the before logic and in the after logic any kind of final changes to the result such as adding additional response or adding additional response cookies or heads Etc but fortunately as of this moment at least there are no any categories of endpoint filters there is only only one type of filters that is supported by minimal API endpoints that itself is called as endpoint filters you can always think of action filters while learning and writing the code for these endpoint filters because they contain the before logic as well as after logic this is the easiest and simple way to create endpoint filter after you create your end point in minimal API by using any map method such as map get map post Etc you will add an endpoint by using add endpoint filter method here you have to supply a delegate that receives the context this context is of endpoint filter invocation context type almost equivalent to action execution context in case of action filters this context allows you to access the HTTP context which in includes with the request object response object session object user object Etc and also it allows you to access the arguments of the end point for example there is a model parameter here or route parameter here you can access that parameter value as a part of the endpoint filter so that you can add validation code for the same let me show that practically here the goal is we have already created the HTTP post endpoint that is map post over here and I would like to add validation code for this product let's say for example the ID cannot be blank and name cannot be blank so first let me add those validation rules in the model class level switch to the model class that is product and add essential validation attributes that is required and others and import the namespace system. component model. data inations the minimum value is zero and maximum is the integer maximum value and of course the product name is mandatory okay we have added essential validation attributes as data annotations in this model class now we have to validate these in this map group so switch to the map group file particularly map post method this is your endpoint delegate or you can say request delate now at the end you can add endpoint filter and it receives an asynchronous delegate that contains two parameters endpoint filter invocation context and endpoint filter delegate as you can guess the context parameter gives you access to the arguments of the request delegate and also the HTTP context for example using this HTTP context you can access the response object request object HTTP context items session and others as we have seen in the beginning of the course for example over here I would like to access the arguments so this arguments represents a collection that contains information about all these argument values including their data types and values this request delegate has two parameters right HTTP context and product particularly we are interested in the second one which is the of product type so we can write like of type it is a link method it Returns the corresponding argument object based on the particular data type that is product so we are querying the particular arguments collection hey arguments collection you have two items with you right one is context and product give me the particular one where the type is is product so it gives the one and what if you have more than one parameter of the same type in that case I would like to get the first one to say that we have to use first or default but what if the product type of parameter does not exist in the to request delegate in that case it returns null because of the first or default so we will receive the argument value and we will check if the product is not equal to n it means it is valid I mean the product object is found okay in case if it is null we have to return error response right return a bad request I mean bad request 400 as response okay this is the message in the response body along with the bad request response but in case if the product object parameter is not equal to null I mean in the request Del get we have successfully received a nonnull value into this parameter in that case it will skip this execution of the if statement and proceed over here now again we have to validate and after creating your validation context in order to perform the validation against the model object create an empty list of validation result into this result we have to load the errors of the model object if any hey buil-in class called validator I would like to validate this particular model object if you ask me what is the object to validate it is product object that is one of the parameters of the request delegate so we are receiving the parameter of the request delegate and validating the same and if you ask me what is the validation context to execute it is the validation context that we have created before removement but in case of any validation errors found for example reord or any other validation is found we have to add essential validation information into this validation result collection and yes I would like to validate all the validation roles not only just required means in case of validate all properties as false it will not perform the validation on other than required attributes so true means you have to validate all the properties including all the data inations okay overall give me a Boolean value whether it is valid or not but in case if it is not valid then we have to return a bad request I mean bad request response with appropriate error message I would like to get the error message from the data annotations in that case you can find all model level validation errors in this errors collection hey errors collection give me the first error message and particularly error message property of the data annotation say for example the ID is not submitted so the required data annotation will be added as an item in the errors collection so we are accessing the first element from the errors collection okay so if the product is null this is the errored message with bad request in case of validation errors this element but what if there are no validation errors in that case it will proceed to the subsequent code it will bypass this if block so the return statement doesn't execute continue execution in that case we have to invoke the next subsequent filter or if no filter exist then we have to execute the request delegate itself see this diagram currently we are on the before logic we are trying to perform the validation of the particular end point still the request delegate of the end point has not executed so after validation in your before logic if no validation errors are found then we have to invoke the subsequent filter if exist otherwise execute the request delegate itself that is what the meaning of next delegate call so we are going to call next so it invokes the subsequent filter or request delegate of the end point see suppose you think of more than one filter is applied after the execution of the before logic of first filter when you call the next it invokes the subsequent filter that is filter number two and as a part of the filter number two if you call next since there are no other filters it executes the request delegate of the end Point itself so always the call to the next invokes the endpoint filter which is subsequent to the current one or the actual endpoint request delegate itself I mean the actual code that you write here will be executed okay after completion of this request to delegate it comes to the after logic so what about the code that is present after for the next delegate call that is considered to be after logic you can use this after logic as a chance to add any kind of final changes to the response such as adding response headers or adding response cookies Etc okay anyways in this particular example we have nothing to do in this after logic so keep it blank the next delegate Returns the subsequent filter if exist otherwise the request delegate of the end point itself and at the end we have to return the same because it is the acceptable return type of the delegate and by the way we have to supply the current working context as argument to the next delegate call the exact point that you should remember is the endpoint filter delegate receives the context T argument you can see that the next delegate returns an endpoint filter delegate which represents the subsequent filter okay let me add the break point in this to see the execution sequence added a breako in the endpoint filter particularly in the before logic as well as in the after logic after the next delegate call whatever present that is after logic suppose add the break point in the return statement and in the same way add a breako in the request delegate of the end point itself here okay run this application and see how it performs the validation now I am trying to make a post request URL is the same p number products and the request body contains the Json information including the product ID as well as name I would like to add this product to the existing collection now make a request okay at first the before logic executes see the actual request delegate does not execute it identifies the end point since the route matches but doesn't execute the request delegate immediately it first executes the filter because the filter is applied now as you can see the context contains all the arguments it contains two arguments in this case one is the context as well as the product object as you can see the ARG one that means the second argument contains a product object with ID and name and this is what we are trying to validate here we have accessed the second argument of the context. arguments into this variable so this product refers to an object of the product that is actually the argument value of the actual request delegate and since it is not equal to null this if block will be skipped there so it continue executing the subsequent code here we perform the model level validation just like what we have done in the service layer earlier and the result is yes it is valid since it is valid that means it has no validation errors this if block will be skipped so no bad request it simply invokes the subsequent filter or the request delegate itself in this case we have added only one filter so there is no any subsequent filter so when you call this next what exactly happens yes you are correct it executes the request delegate of the end point so the filter execution will be passed there and it executes the actual request delegate so it receives the same product object as you can see with the product ID as well as name same values and after that we are adding that product object into the collection and then return the result I mean okay result with the 200 response status code and here is the point after completion of this end point request delegate it continues executing the after logic of the filter so in this way it works almost equivalent to asynchronous action filter only the difference is the terms are changed instead of calling it as action filter we are calling it as endpoint filter that's the difference so for understanding wise coding wise action filters endo filters almost play in the same role but technically speaking you cannot apply the action filters directly to the minimal API end points but alternatively you can apply the endpoint filters much like what we have created as action filters earlier Okay click on continue so we have executed the before logic first then the end point request to delegate itself which contains Act code to execute and after that the after logic and you can see the response over here with status code 200 but in this application the big complaint is if the endpoint filter has significant amount of code it will be too conversome and lengthy to write everything in the same file that is along the side of end point Point code so it will be better if you can separate the filter code in a separate file something like creating an endpoint filter separately and applying the same just like what we have done earlier while creating asynchronous action filters we will try that in the next lecture and by the way another point is if more than one endpoint filter is applied for the same endo they execute in fifo order first in first out for example you have applied filter one first and then filter two so it executes the before logic of the filter one and then before logic of the filter 2 and then the request delegate of the end point then in case of after Logic the same will be reversed obviously so then it executes the after logic of the filter 2 and then after logic of the filter one as reversed to the fif at your practice time you try to create and apply more than one endpoint filter to the same end point
2024-12-22 05:53
