We are looking at using the Validate API Specification policy in our API. Out incoming payload will be JSON. I was hoping we could use a JSON schema to validate our request payload but it seems only XML Schemas can be used. The only option is XML Schema:
I suspect an answer to your query is likely to be a custom extension to do the validation within the IS that is hosting GW.
But i wanted to explore whether or not that should be done in GW. Whenever I see a proposal to “validate the message” in the middle, I usually have a concern. The concern is driven in part by previous cases where validation and enforcement was implemented in wM IS components, and over time removed because the end point really did not need it done on their behalf. For example, there was case where wM IS would block a message because it was missing an element, or had a value that was previously requested to be blocked – and when it was blocked the target said “oh, we need that now, pass it through anyway.” They had forgotten it was blocked.
Similar scenarios have repeated over the years. And with the evolution of apps and pretty much every app having the ability to “do JSON over HTTP” the need for middleware validation and enforcement to prevent “bad” data from reaching an app has significantly diminished.
So my query here is – does the payload validation really need to occur in GW or does the native service already do it? If the native service already verifies things, does it make sense for GW to duplicate that? In most of the cases we’ve implemented in the past few years, we don’t do schema validation “in the middle” (API GW or IS). Structure (valid XML, JSON) is inherently validated at times (string to doc) but nowhere is it enforced that, for example, “xyz” element is present.
If your API is specified (and your proxy created) using either OpenAPI Specification v3 or v2 (aka Swagger), then you can validate request and response payloads according to their JSON schemas.
The “XML Schema” thing is indeed very misleading. Ignore it, just tick the Schema box.
I am currently working on demos with these features and they work very nicely.
This is your opinion.
Validating requests at implementation level is tedious, and in a lot of situations the runtime will generate dirty deserialization errors.
A lot of developers also generate JSON responses that are not scheme compliant. I’ve seen in many times with code written in Javascript.
So dealing with schema validation at middleware level makes sense in that situation.
It ensures consumers get clear error messages regarding their requests, and it protects backends.
It also allows you to easily detect non compliant responses during tests phases. Even with Postman, detecting non compliant JSON is difficult…
Good feedback.
What we are creating is net-new. I agree with Stephane in this case since we would rather the API gateway enforce the schema to save embedding logic in an on-prem wM IS service. If the JSON payload sent to us from the consumer doesn’t conform to the spec, then they will get an immediate reply. We prefer to do this instead putting too much validation logic in our on-premise endpoint (which in our case is an IS REST service in an on-premise wM Integration Server).
Our schema will catch issues such as required fields, and min / max length issues.
If we need additional more complex validation, we will likely do this in the endpoint service but we hope to catch most of the issues immediately in the gateway. @Stephane.TAILLAND_emp
Thanks for pointing out that JSON schema can be used. I may ping you wuth more questions.
The wM.io API GW UI is misleading. The wM.io API gateway documentation seems to indicate that JSON schemas can be used. Once we saw only an option for XML Schema that gave us doubts, which resulted in my post.
I will have to speak with my contacts at Software AG about this confusion
Absolutely! Unless I’m quoting documentation, it usually is.
My only intent was to share rationale to consider not doing this in the middle. Certainly there are times when it makes sense. I tend to fall in the camp “only if there is absolutely no other place to do it and the world will end without it”. Another couple of the guiding principles I tend to follow is don’t do it in the middle just because you can and do in the middle only what is absolutely necessary
Certainly others will judge what works best for them. What is one person’s must do might be another person’s nice to have or “absolutely not”.
I obviously don’t know all of the components involved and the functions needed, but IMO validation logic generally shouldn’t be in wM IS either. It should be in whatever system IS is calling (if any). Of course, if IS is hosting the entire service (e.g. fronting a DB) or fronting an application that has no capabilities itself then putting the logic there makes sense, or in API GW – depending on if no one will/can bypass GW and call IS directly. Many aspects to consider of course.
