Open TheNitek opened 9 years ago
Hi, well that is currently not on the scope. The idea of the analyzer is to be as close to the JAX-RS standard as possible -- meaning that the generated REST documentation should match all resources available when the JAX-RS project would be deployed to the container.
However, to get a better understanding, what exactly are you trying to achieve? Do you have a large project which consists of several logically separated set of endpoints for which you would like to have separate documentations?
What I possibly could imagine would be something like black- / whitelisting resource classes in the configuration. One could then have several runs of the analyzer, all with different configurations to get their desired parts.
Well, it's not a very large project, but we basically have two APIs (one private and one public one). The client system is only interested in one of them. Since I want to provide them with a changelog now, I'd like to avoid to confuse them with changes they will never see, because they belong to the other "side" of the API. That's why filtering by class (or URI) would really help.
This also would be the case for RestEasy Proxies (https://docs.jboss.org/resteasy/docs/3.0-beta-3/userguide/html/RESTEasy_Client_Framework.html#d4e2049) For now the analyzer also proceed the interface and generate an endpoint documentation for this. But in reality the interface is used to build a REST client.
It would be great if the analysis could be limited to specific classes only. So if you have different classes providing different APIs (but all in the same package), you are still able to generate different result files.