Option to filter APIs based on their http-security

[wrygiel]

Previously, we wrote (here) that Java Registry Client won't help developers with filtering APIs based on their <http-security>. Quote:

• If you are using the Java Registry Client, then you will need to use the findApis method (instead of the regular findApi), and filter the returned Collection<Element> yourself. The existing ApiSearchConditions class doesn't allow you to filter APIs based on the contents of their <http-security> element.
• Note, that the existence of the <http-security> element depends on the designers of the particular API. EWP Registry does not force its APIs to use any single security model. It's up to the API designer to choose its security model. This way, many other APIs (such as EMREX, for example) can be easily included in the EWP Registry in the future (without them being forced to switch to our v2-security model). It also means, that Java Registry Client cannot "natively" allow you filter APIs based on their security settings.

However, I am not certain about this. Perhaps we can bend the rules a bit, and include some v2-security-specific code in the common Registry Client. After all, we expect that most APIs will follow v2-security, so it would make sense to allow ApiSearchConditions to filter on them.

Not sure how the new methods should look like though.

[wrygiel]

Solution 1 - filter by a Predicate

Add a ApiSearchConditions method which would filter APIs by a supplied Predicate<Element>.

Predicate was introduced in Java 8. Perhaps we should use an alternative class to stay compatible with Java 7.

This method would allow client implementers to include any kind of filter. However, it's not very easy to use, because implementers will need to implement Predicates by themselves. Perhaps we can do better than that.

[wrygiel]

Solution 2 - setRequiredHttpSecurityOptions

We could also add a ApiSearchConditions.setRequiredHttpSecurityOptions method with would take:

• A relative XPath expression pointing to the <http-security> element expected to be present in the Element. The namespace of the XPath expression would need to be the same as the namespace of the API entry itself. We could also have an overloaded implementation which would assume that the value for this XPath is simply ./http-security.
• A new HttpSecurityOptions class which would describe the set of security methods supported by the client.

Perhaps we should name this method a bit differently, in order to make it obvious that not all APIs declare these security options. For example, setRequiredEwpV2Security.

[wrygiel]

If we choose solution 2 though, then we will need to update the Registry Client every time a change occurs in any of the security-entries.xsd files (which are defined in repositories of each security method). It will become somewhat messy. Perhaps it would be better to choose Solution 1, and possibly publish a separate "v2-securty" library for generating Predicates.

Unfortunately, I am leaving for vacation now, so I won't have time to solve this issue in the next weeks. For now, implementers should implement the filtering by themselves.

[wrygiel]

I'm not sure how much "wanted" this feature is. Should I try to implement it before a leave the project?

[Emkas]

As of 2022, we have just one security option. I think this issue can be closed as 'Won't fix'.