Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[policy] [json-validation] enabling response scope for gravitee-policy-json-validation #2825

Closed

Comments

@kirkondrash
Copy link

@kirkondrash kirkondrash commented Oct 31, 2019

Currently json-validation policy works only on request phase. Is there any particular reason why a response_content scope is not implemented in the policy similarly to request_content scope?

Expected Behavior

json-validation policy having a response_content scope option

Current Behavior

json-validation policy has only request_content scope option

Possible Solution

create an onResponseContent() method in a similar fashion as onRequestContent(), which will send the client a 500 response and the same error keys as for request if the json body has failed to validate.

Context

In my case a necessity to validate responses also exists - as for all APIs I want to enforce strict rules for bodies format. If the server response does not conform the rules, the client should not not receive such response, receiving the 500 code instead for example. Then it is up to admins and the owner of the service to analyze why the clients are receiving the 500 code through the logs, etc.

@aelamrani

This comment has been minimized.

Copy link
Member

@aelamrani aelamrani commented Oct 31, 2019

Hi @kirkondrash
I'm not sure I understand the purpose of this question.
The API publisher is supposed to govern/control its API. So why should he define this type of validation rule in an API Gateway?

@kirkondrash

This comment has been minimized.

Copy link
Author

@kirkondrash kirkondrash commented Oct 31, 2019

Hi, and thanks for a quick answer.
I am supposing the situation, where the one owning and supporting the gateway is not the same person as the one creating the APIs which will be served on the gateway. So aside of some written or verbal agreements shaping the API which will be deployed on the platform, it would be good to be able to technically enforce some rules to control the fulfilment of the aforesaid agreements. For example, if the clients wants to get the same kind of information - for example, info on his account - from different APIs, the responses from all of them will contain the necessary fields, etc.

@kirkondrash kirkondrash changed the title [gateway] enabling response scope for gravitee-policy-json-validation [policy] [json-validation] enabling response scope for gravitee-policy-json-validation Oct 31, 2019
@aelamrani

This comment has been minimized.

Copy link
Member

@aelamrani aelamrani commented Oct 31, 2019

Ok, I understand why you want to add this type of control, but I'm not sure that the degradation of the service is a good option for consumers.
Moreover, adding this type of coupling on the format of the answer would be an error for me.
The validations that you can find in a service contract concern the query / payload fields and never the response.

@kirkondrash

This comment has been minimized.

Copy link
Author

@kirkondrash kirkondrash commented Oct 31, 2019

For me, when providing third-party APIs through Gravitee platform it is important to control what these APIs are sending to customers. Swagger, for example (I suppose it can be referred as the service contract to some extent), provides the same possibilities for describing the responses, as for request bodies. Still thanks for your response, if this is not fitting into general concept of gravitee platform I am not planning on pushing any further.

@aelamrani

This comment has been minimized.

Copy link
Member

@aelamrani aelamrani commented Oct 31, 2019

I keep this issue open as there is a real need when providing third party APIs.
We can easily add the possibility to define rules on response payload that's not the point and we will do it.

I just wondering what could be the better solution / options to avoid to degrade the service from a user point of view.

@brasseld

This comment has been minimized.

Copy link
Member

@brasseld brasseld commented Oct 31, 2019

I just wondering what could be the better solution / options to avoid to degrade the service from a user point of view.

It depends on the use case, but I wonder if we could not just handle it with an additional configuration property...

@kirkondrash

This comment has been minimized.

Copy link
Author

@kirkondrash kirkondrash commented Oct 31, 2019

Maybe a boolean parameter could be added - depending on it will be decided, whether still to send the user the response, which body failed to validate, or not. In both cases, validating error will be logged for further inspection. The parameter will help, for example, when the validation rule has just been changed and not all the APIs have already been adjusted. Thus, the clients will still be getting the responses - so there won't be sudden degadation, and the administrators of the platform will know what APIs are having problems with new changes.

@kirkondrash

This comment has been minimized.

Copy link
Author

@kirkondrash kirkondrash commented Nov 11, 2019

Just wondering if there has been any progress with the discussions.

@kirkondrash

This comment has been minimized.

Copy link
Author

@kirkondrash kirkondrash commented Nov 18, 2019

@aelamrani, @brasseld is there any other info I need to provide, or, maybe, are there any other possible solutions/workarounds for this issue?

@aelamrani

This comment has been minimized.

Copy link
Member

@aelamrani aelamrani commented Nov 18, 2019

@kirkondrash do you think you can provide a pull request for this?
I think we can provide the same behavior in response and request and think about an improvement in another issue. WDYT?

@kirkondrash

This comment has been minimized.

Copy link
Author

@kirkondrash kirkondrash commented Nov 21, 2019

We are ready to implement this feature; however, there is a problem in where is the right place to log the messages of failed validation. In contrast with Request, currently there are no metrics gathered in Response. We are planning to set server response validation error as request metric message – to my mind, there is not much irrationality in saying that “Server returned bad response for this exact request”. Won’t it break anything or do we have to go the long way of implementing metrics functionality for responses in this case?

@brasseld

This comment has been minimized.

Copy link
Member

@brasseld brasseld commented Nov 21, 2019

You can add the request object in method parameters, which allows you to get reference to metrics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
API Management
Awaiting triage
3 participants
You can’t perform that action at this time.