Feedback wanted: Allowing policies to modify PolicyFailures emitted by *other* policies in chain
by Marc Savy
Marvin Oßwald filed a really interesting issue:
https://issues.jboss.org/browse/APIMAN-1300
In short, if we imagine a policy chain like this:
[CORS, PolicyA, PolicyB]
Even if PolicyB emits a failure, then the CORS policy would likely
still want to be able to process the PolicyFailure to add the relevant
headers (otherwise a SPA type app like Angular would break).
This seems like a valid use-case.
Ideally I'd like to tackle this without breaking any existing interfaces.
A couple of quick ideas:
* Add a new interface that policies like CORS could implement that
indicates it wants to do this kind of processing. E.g.
IFailureProcessor or similar with a simple method signature like
#process(PolicyFailure failureToModify).
* An annotation: essentially the same as above, but with a
@WhateverWeCallIt annotation on the method that does the processing.
6 years, 4 months
Is it possible blocking request after request body parsing?
by 林 柏廷
Hi all,
I would like to customize a policy, which parses the request body and blocks the request in case.
in http://www.apiman.io/latest/developer-guide.html 4.2.1.2 IData policy, it describes:
The request or response body will not begin streaming before the corresponding doApply has been called, however, it is still possible to interrupt the conversation during the streaming phase by signalling doFailure or doError.
When I trace the transformation-policy source code, doApply() executes before getRequestDataHandler() which matches the description.
In doApply() I can blocks the request via chain.doFailure() however I have no idea how to interrupt/block request in getRequestDataHandler().
Besides, I found following mail group which is similar to my question.
Eric also points it's possible to parse the body before apply in request:
On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <
eric.wittmann at redhat.com> wrote:
The bottom line here is that you cannot return a Policy Failure (or
customize it) based on information in the response body. The response is
streamed from the back-end to the client, and at the time streaming begins,
the response code and HTTP headers have already been sent.
It sounds to me like you're asking for a feature where you can parse
the response body *before* the policy's "apply" method is invoked. we have
such a feature for requests, but not for responses. I suspect core changes
to apiman would be required to enable that. It seems like a reasonable
request to me, as long as users of the feature understand the performance
and memory requirements of enabling it.
-Eric
Thanks for any comments in advance.
Kind Regards
BT
6 years, 5 months
Re: [Apiman-user] APIMan support for HATEOAS
by Ashish Patel
Hi,
If below is not feasible, any suggestions to handle it through APIMan ?
Thanks & Regards,
Ashish Patel
From: Ashish Patel
Sent: Tuesday, April 17, 2018 12:31
To: apiman-user(a)lists.jboss.org
Subject: APIMan support for HATEOAS
Hi,
Has anyone tried exposing APIs having HATEOAS - 'Hypertext As The Engine Of Application State' through APIMan, can you please suggest how below two scenarios are handled ?
1) How to register URLs like "/transaction/{serviceRequestNo}/save , "/transaction/{transactionId}/{transactionType} ..etc ?
2) GET response JSON returned by a server to a client having reference to APIGateway URLs and not actual servers' URL.
In case, if I am not clear enough, please refer https://dzone.com/articles/api-gateway-support-hypertext (very old article - states what is requested).
Thanks & Regards,
Ashish Patel
6 years, 7 months
Production Upgrade Recommendation
by Ashish Patel
Hi,
Currently we are in production with APIMan 1.2.7.Final with Willdfly 10 (both APImanUI and APImanGateway, Keycloak on separate server). We are planning to upgrade to latest version 1.3.1.Final and need recommendation on deployment strategy. As per Download page we have following options (please add if any missed).
For Upgrading from APIman 1.2.7 to APIman 1.3.1
1. APImanUI and APImanGateway both on Wildfly 10 .
2. #1 deployment through Docker.
3. APImanUI and APImanGateway both on Tomcat8+
4. APImanUI on Wildfly10 and APIGateway on Vert.x
Looking for stable and high throughput deployment choice - as per my limited knowledge #4 would be the best - however I may be wrong based on actual usage. Appreciate the feedback.
Thanks in advance.
Thanks & Regards,
Ashish Patel
6 years, 7 months
Re: [Apiman-user] APIMAN-1304 UI bug and doing another unplanned 1.3.x release
by Marc Savy
Hi,
A community user trying out 1.3.3.Final has found another UI issue
which will likely require another release. It is in the create
contract dialogue and can result in unexpectedly being redirected back
to the home screen.
It's unfortunate it wasn't caught before release, but it only happens
on a particular pathway and is a side-effect of the recent
security-related dependency updates.
The fix is only a couple of lines.
Please try out the latest master of Apiman, and I'll try to do a
1.3.4.Final release shortly.
In other news: the ES 1.5.x support is coming along nicely and should
be available shortly.
Thanks again to the community for helping out.
Regards,
Marc
6 years, 7 months
Proposed change: Apiman 1.4.x will move to Elasticsearch 5.x
by Marc Savy
As discussed previously, we plan to upgrade Apiman's ES support to 5.x.
1.3.3.Final is the final (planned) release to support ES 1.x. We don't
anticipate doing another 1.3.x release unless serious regressions are
found.
Is ES 2.x support important to folk? We didn't upgrade previously
because ES 2.x didn't support bulk delete queries - however, they
added that back latterly with a plugin.
Any other requests or feedback welcome.
Regards,
Marc
6 years, 7 months
Proposed removal: Hawkular Metrics
by Marc Savy
Hi,
We are proposing the removal of Hawkular Metrics from Apiman shortly.
If this would cause you any issues (i.e. you're using Hawkular Metrics
in Apiman) then please let us know.
Regards,
marc
6 years, 7 months
Apiman 1.3.3.Final released
by Marc Savy
We've done a 1.3.3.Final release of Apiman to fix a regression with
swagger-ui in 1.3.2.Final.
An upside of the fixes is that OpenAPI 3.x documentation is now also
supported (in addition to Swagger/OAI 2.x).
Thanks to the community for the feedback that went into this release.
Regards,
Marc
6 years, 7 months
