<div dir="ltr">Here's the PR for those who want to track progress:<div><br></div><div><a href="https://github.com/apiman/apiman-cli/pull/27">https://github.com/apiman/apiman-cli/pull/27</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 July 2017 at 23:34, Marc Savy <span dir="ltr"><<a href="mailto:marc.savy@redhat.com" target="_blank">marc.savy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here's a preview of my proposed data format -- it reuses the format<br>
and model developed by Pete Cornish and his team; big kudos to them!<br>
[1].<br>
<br>
I'm soliciting suggestions and comments, feel free to reply here (or<br>
reach out privately if that's not possible).<br>
<br>
Example:<br>
<br>
apiman-cli gateway apply -f /Users/msavy/tmp/sample.yaml<br>
<br>
```<br>
# sample.yaml<br>
---<br>
system:<br>
gateways:<br>
- name: "test-gw"<br>
type: "REST"<br>
config:<br>
endpoint: "<a href="http://localhost:8080/apiman-gateway-api" rel="noreferrer" target="_blank">http://localhost:8080/apiman-<wbr>gateway-api</a>"<br>
username: "apimanager"<br>
password: "apiman123!"<br>
plugins:<br>
- name: TestPolicyFriendlyName // (1)<br>
groupId: "io.apiman.plugins"<br>
artifactId: "apiman-plugins-test-policy"<br>
version: "1.3.1.Final"<br>
org:<br>
name: "test"<br>
apis:<br>
- name: "example"<br>
version: "1.0"<br>
config:<br>
endpoint: "<a href="http://localhost:8080/services/echo" rel="noreferrer" target="_blank">http://localhost:8080/<wbr>services/echo</a>"<br>
endpointType: "rest"<br>
public: true<br>
gateway: "test-gw"<br>
policies:<br>
- name: "CachingPolicy" // (2)<br>
config:<br>
ttl: 60<br>
- plugin: TestPolicyFriendlyName // (3)<br>
config:<br>
foo: 123<br>
```<br>
(1) Friendly name for plugin instead of having to refer to it by full GAV<br>
(2) In-built policy will be looked up to ensure it exists and resolves<br>
the correct FQCN.<br>
(3) Add a policy by plugin friendly name (else GAV)<br>
<br>
One rare edge case when multiple policies are defined in a single<br>
plugin. In that situation we allow disambiguation by providing the<br>
plugin's `id` in the `name`/`id` field:<br>
<br>
```<br>
<SNIP><br>
policies:<br>
- name: PolicyOne<br>
plugin: PluginWithMultiplePolicies<br>
config:<br>
foo: 123<br>
```<br>
<br>
Thoughts? Feedback?<br>
<br>
Still a bit of work to do before it's PR-ready but making some progress.<br>
<br>
Regards,<br>
Marc<br>
<br>
[1] With one tiny addition.<br>
<div class="HOEnZb"><div class="h5"><br>
On 7 July 2017 at 14:29, Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>> wrote:<br>
> We've had some people using the Apiman Gateway headless for a while<br>
> now, either with the new immutable registry that loads from JSON[1],<br>
> or simply using any existing registry via the gateway API instead of<br>
> using a manager.<br>
><br>
> The main issue people encounter is that policy configuration contains<br>
> two fields that are difficult to work out and clumsy to encode<br>
> properly[1]:<br>
><br>
> - `policyImpl` requires the plugin's URI, including the path to its<br>
> main class. You can work these out by looking at the plugin's source<br>
> code, but that's rather circuitous and it would be nicer to just<br>
> provide the plugin's GAV (like in the manager) and for it to be<br>
> resolved.<br>
><br>
> - `policyJsonConfig`[3] needs to be escaped properly (and must valid<br>
> according to its schema).<br>
><br>
> Neither of these aspects are especially user-friendly. My proposal is<br>
> to extend apiman-cli's functionality to allow the Apiman Gateway to be<br>
> configured directly via a YAML/JSON file (i.e. declaratively).<br>
><br>
> We can therefore provide a more user-friendly interface that automates<br>
> the resolution of plugins; validations and escapes the policy config;<br>
> etc.<br>
><br>
> A final step would be to bundle the apiman-cli tool with our distros<br>
> to make it easier to access.<br>
><br>
> Any thoughts?<br>
><br>
> Regards,<br>
> Marc<br>
><br>
> [1] <a href="https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/vertx/download.html#_elasticsearch" rel="noreferrer" target="_blank">https://apiman.gitbooks.io/<wbr>apiman-installation-guide/<wbr>installation-guide/vertx/<wbr>download.html#_elasticsearch</a><br>
> [2] Of course, this interface was never truly designed to be used by<br>
> humans, so that's understandable<br>
> [3] Unfortunately named as it can be any arbitrary string, the policy<br>
> just needs to be able to decode it. For example, it could be XML.<br>
</div></div></blockquote></div><br></div>