<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández <span dir="ltr">&lt;<a href="mailto:jhernand@redhat.com" target="_blank">jhernand@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/27/2015 11:28 AM, Roman Mohr wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández &lt;<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a><br>
</span><span class="">&gt; &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     On 10/27/2015 10:16 AM, Roman Mohr wrote:<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández &lt;<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
</span><span class="">&gt;     &gt; &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt; wrote:<br>
&gt;     &gt;<br>
</span><div><div class="h5">&gt;     &gt;     On 10/26/2015 04:56 PM, Roman Mohr wrote:<br>
&gt;     &gt;     &gt; Hi Juan,<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; The way to specify the contract look pretty clean and nice.<br>
&gt;     &gt;     &gt; I would love to read a few words about the big picture. What<br>
&gt;     is the<br>
&gt;     &gt;     &gt; final scenario?<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     The motivation for this change is that currently we don&#39;t have<br>
&gt;     a central<br>
&gt;     &gt;     place where the RESTAPI is specified, rather we have several<br>
&gt;     different<br>
&gt;     &gt;     places, using several different technologies:<br>
&gt;     &gt;<br>
&gt;     &gt;     * XML schema for the data model.<br>
&gt;     &gt;     * JAX-RS for part of the operational model (without the<br>
&gt;     parameters).<br>
&gt;     &gt;     * rsdl_metadata.yaml for the parameters of the operational model.<br>
&gt;     &gt;<br>
&gt;     &gt;     This makes it difficult to infer information about the model. For<br>
&gt;     &gt;     example, the generators of the SDKs have to download the XML<br>
&gt;     schema, and<br>
&gt;     &gt;     the RSDL (which is generated from the JAX-RS interfaces using<br>
&gt;     reflection<br>
&gt;     &gt;     and combining it with the information from the<br>
&gt;     rsdl_metadata.yaml file)<br>
&gt;     &gt;     and then they have to do their own computations to extract<br>
&gt;     what they<br>
&gt;     &gt;     need.<br>
&gt;     &gt;<br>
&gt;     &gt;     Same happens with the CLI: it has to extract the information<br>
&gt;     it needs<br>
&gt;     &gt;     from the Python code generated for the Python SDK, yet another<br>
&gt;     level of<br>
&gt;     &gt;     indirection.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; You are right, that definitely needs to be cleaned up. I just want to<br>
&gt;     &gt; discuss a few points below with you.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     We are also lacking a comprehensive reference documentation of the<br>
&gt;     &gt;     RESTAPI. What we currently have has been written by hand, and<br>
&gt;     gets out<br>
&gt;     &gt;     of sync very quickly, and we don&#39;t even notice.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; Did you also consider swagger? It is made for exactly that purpose.<br>
&gt;     &gt; I created a demo in [1] which uses resteasy, weld, hibernate-validator<br>
&gt;     &gt; and swagger to demonstrate how to do DRY with jaxrs.<br>
&gt;     &gt; Would be great to hear you thoughts on that.<br>
&gt;     &gt;<br>
&gt;     &gt; And there is the great swagger-ui [8] to display the documentation<br>
&gt;     in a<br>
&gt;     &gt; more human readable way.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Yes, I considered Swagger, and rejected it because it is JSON centric,<br>
&gt;     and I think JSON isn&#39;t as good as Java to represent the contracts of our<br>
&gt;     RESTAPI.<br>
&gt;<br>
&gt;<br>
&gt; You just write plain jax-rs, swagger just creates a description out of<br>
&gt; it. So  the source defining the contract is pure java (jax-rs with some<br>
&gt; swagger annotations for description, etc.).<br>
&gt; Or am I missing the point here?<br>
&gt;<br>
<br>
</div></div>If I understand correctly the Swagger core is a JSON (or YAML)<br>
specification of the API. From that you can generate JAX-RS annotated<br>
code, not the other way around. So the specification document that you<br>
write is a JSON document.<br>
<br>
Alternatively, you can use the Swagger annotations to decorate your<br>
implementation, both the entity classes and the JAX-RS resource<br>
implementations, and then extract the model from that. But this is<br>
putting the implementation before the specification. That is where we<br>
are today, and it causes multiple problems. I think it is better to have<br>
the specification and the implementation separate. Swagger does that<br>
well when using JSON directly, our metamodel also does it well, but<br>
using a better language.<br>
<span class=""><br>
&gt;<br>
&gt;<br>
&gt;     In addition we need to do these changes in a smooth way, without causing<br>
&gt;     big changes in the middle. For example, in the first step we need to<br>
&gt;     preserve the JAX-RS interfaces as they are today, to avoid massive<br>
&gt;     changes to all the resource implementations. This could be done with<br>
&gt;<br>
&gt;     Swagger, but would require custom code generators. With less effort we<br>
&gt;     can do our own.<br>
&gt;<br>
&gt;<br>
&gt; This is of course generally a difficult task. But I do not know why it<br>
&gt; would be more difficult to write a custom swagger reader (if we even<br>
&gt; have to, it can read the interfaces as well) .<br>
&gt; They are pretty streight forward. Just look at [9], this contains the<br>
&gt; wole jax-rs specific code to generate the swagger documentation.<br>
&gt;<br>
&gt; But yes, I don&#39;t know every detail here of the engine and can&#39;t clearly<br>
&gt; say that integrating that would just streight forward (my feeling tells<br>
&gt; me that it would not be too hard). I am just under the impression that<br>
&gt; we would benefit from that. Just reduces custom magic to a minimum.<br>
&gt;<br>
<br>
</span>Using something like Swagger would be certainly possible, and not that<br>
hard, but it requires an effort. For example, say that we decide to use<br>
the Swagger annotations. Then we will need to add these annotations to<br>
all our JAX-RS resource implementations. That is a non trivial effort.<br>
We would need to add the annotations to the entities as well. But wait,<br>
we don&#39;t have such entities, only XML schema. So we would need a reader<br>
that parses XML schema, and creating it requires effort. Where do we put<br>
the documentation then? Part in the JAX-RS interfaces, part in the XML<br>
schema. We are already there, and we ended up with no documentation at<br>
all. In my view the sum of these efforts is higher than doing our own<br>
metamodel.<br>
<div><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt;     Swagger UI is certainly great. I did test it and it is really good. We<br>
&gt;     may be able to copy some concepts.<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     To solve these issues I intend to have the specification of<br>
&gt;     the RESTAPI<br>
&gt;     &gt;     only in one place, and using only one technology. I decided to<br>
&gt;     use Java<br>
&gt;     &gt;     interfaces for that. Note however that they are just the<br>
&gt;     support for the<br>
&gt;     &gt;     information, like paper is the support for ink. I decided to<br>
&gt;     use Java<br>
&gt;     &gt;     because it is easy to create, modify and re-factor using tools<br>
&gt;     familiar<br>
&gt;     &gt;     to most of us.<br>
&gt;     &gt;<br>
&gt;     &gt;     These source of these interfaces is analysed (using QDox,<br>
&gt;     currently) and<br>
&gt;     &gt;     a &quot;model&quot; of the RESTAPI is generated in memory. This model is<br>
&gt;     &gt;     independent of the supporting Java source, and easy to<br>
&gt;     consume. For<br>
&gt;     &gt;     example, imagine that you want to list all the types available<br>
&gt;     in the<br>
&gt;     &gt;     model and for each one display its documentation:<br>
&gt;     &gt;<br>
&gt;     &gt;       Model model = ...;<br>
&gt;     &gt;       for (Type type : model.getTypes()) {<br>
&gt;     &gt;         Name name = type.getName();<br>
&gt;     &gt;         String doc = type.getDoc();<br>
&gt;     &gt;         System.out.println(name + &quot;: &quot; + doc);<br>
&gt;     &gt;       }<br>
&gt;     &gt;<br>
&gt;     &gt;     Something like this, but more elaborate, will be part of a web<br>
&gt;     &gt;     application that provides comprehensive reference documentation,<br>
&gt;     &gt;     assuming that we dedicate the time to write documentation<br>
&gt;     comments in<br>
&gt;     &gt;     the specification.<br>
&gt;     &gt;<br>
&gt;     &gt;     I intend to use this model also to do simplify the generators<br>
&gt;     of the<br>
&gt;     &gt;     SDKs and the CLI.<br>
&gt;     &gt;<br>
&gt;     &gt;     In addition these are some of the things that I would like to<br>
&gt;     change in<br>
&gt;     &gt;     the near future (for 4.0):<br>
&gt;     &gt;<br>
&gt;     &gt;     * Move the specification of the parameters of operations out<br>
&gt;     of the<br>
&gt;     &gt;     rsdl_metadata.yaml file and into the model. For example:<br>
&gt;     &gt;<br>
&gt;     &gt;       @Service<br>
&gt;     &gt;       public VmService {<br>
&gt;     &gt;         /**<br>
&gt;     &gt;          * The operation to add a virtual machine.<br>
&gt;     &gt;          */<br>
&gt;     &gt;         interface Add {<br>
&gt;     &gt;           /**<br>
&gt;     &gt;            * The representation of the virtual machine is received<br>
&gt;     &gt;            * as parameter, and the representation of the created<br>
&gt;     &gt;            * virtual machine is returned as result.<br>
&gt;     &gt;            */<br>
&gt;     &gt;            @In @Out Vm vm();<br>
&gt;     &gt;<br>
&gt;     &gt;            /**<br>
&gt;     &gt;             * In the future, we will be able to specify other<br>
&gt;     &gt;             * parameters here.<br>
&gt;     &gt;             */<br>
&gt;     &gt;            @In Boolean force();<br>
&gt;     &gt;<br>
&gt;     &gt;            /**<br>
&gt;     &gt;             * Even with default values.<br>
&gt;     &gt;             */<br>
&gt;     &gt;            @In default Boolean force() { return true; }<br>
&gt;     &gt;<br>
&gt;     &gt;            /**<br>
&gt;     &gt;             * And we will be able to specify constraints, which<br>
&gt;     &gt;             * will replace the rsdl_metadata.yaml file.<br>
&gt;     &gt;             */<br>
&gt;     &gt;            @Constraint<br>
&gt;     &gt;            default boolean vmNameMustNotBeNull() {<br>
&gt;     &gt;              return vm().name() != null;<br>
&gt;     &gt;            }<br>
&gt;     &gt;          }<br>
&gt;     &gt;       }<br>
&gt;     &gt;<br>
&gt;     &gt;     * Enforce the constraints automatically. If the constraints<br>
&gt;     are in the<br>
&gt;     &gt;     model, then we can just check them and reject requests before<br>
&gt;     delivering<br>
&gt;     &gt;     them to the application. Currently we do this manually (and often<br>
&gt;     &gt;     forget) with calls to &quot;validate(...)&quot; methods.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; Did you consider just annotating the DTOs with JSR-303 annotations and<br>
&gt;     &gt; integrate a validator with jax-rs?<br>
&gt;     &gt; See [2] for an example.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     This is a great way to implement a system, but the goal here isn&#39;t to<br>
&gt;     implement it, rather to specify it. Using annotations in this way won&#39;t<br>
&gt;     help the generators of the SDKs, for example, to figure out what<br>
&gt;     parameters are required, mandatory, etc.<br>
&gt;<br>
&gt;<br>
&gt; Swagger understands them. From my example project, swagger created that<br>
&gt;<br>
&gt;      description:<br>
&gt;         type: &quot;string&quot;<br>
&gt;         minLength: 10<br>
&gt;         maxLength: 100<br>
&gt;<br>
&gt; out of<br>
&gt;<br>
&gt;      @Size(min=10, max=100) # jsr-303<br>
&gt;      private String description;<br>
&gt;<br>
&gt; and so does swagger-codegen which can generate clients in java, python, ...<br>
&gt;<br>
<br>
</div></div>This is extracting the specification from the implementation, which<br>
isn&#39;t correct in my opinion, it should be the opposite. Not saying that<br>
this makes Swagger bad, it is nice that it has this capability, but I<br>
think we can do it better.<br>
<span class=""><br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     * Generate the Java classes directly from the model. Instead of Model -&gt;<br>
&gt;     &gt;     XML Schema -&gt; Java, we can do Model -&gt; Java. This will allow us to solve<br>
&gt;     &gt;     some of the XJC compiler limitations, like the horrible way we handle<br>
&gt;     &gt;     arrays today.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; Swagger [3] is a rest documentation specification. There is also a maven<br>
&gt;     &gt; plugin [4] and you can create clients for example with [5].<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     * Replace JAX-RS with a simpler infrastructure that supports better<br>
&gt;     &gt;     streaming and CDI injection.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; With resteasy-cdi you have pretty good injection support for resteasy.<br>
&gt;     &gt; Run the demo in [1] to see it in action and look at the file at [6].<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Resteasy-CDI isn&#39;t standard, it only works with Resteasy. If we rely on<br>
&gt;     it then we re tied to Resteasy for ever.<br>
&gt;<br>
&gt;<br>
&gt; Even jersey has support for that (I think it is called jeryse-gf-cdi),<br>
&gt; but why would we want switch? I don&#39;t think that jboss will drop<br>
&gt; resteasy and it also works fine outside of full blown containers. I<br>
&gt; don&#39;t think that this is an argument.<br>
&gt;<br>
<br>
</span>Well, nobody thought that JBoss would drop Tomcat, and they did. Nobody<br>
thought that Resteasy would change the SPI from 2.x to 3.x, and they did.<br>
<br>
We want (well, I want) to get out of JAX-RS because it doesn&#39;t support<br>
well CDI and streaming.<br><div class="HOEnZb"><div></div></div></blockquote><div><br></div><div>By the way why do you think it does not support streaming well? As far as I know there are StreamingOutputs for specific endpoints and you can always plug in your own MessageBodyWriter which can serialize item by item of a list to return everything in a stream like fashion. If you use lazy evaluating collections like guava does for a long time for many things we would be pretty much do what you are after, right? JAX-RS is not the problem here, just standard jackson message body writers do not do it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     * Add support for multiple versions of the API, using the &quot;Version&quot;<br>
&gt;     &gt;     header, and generating different Java classes for entities and services.<br>
&gt;     &gt;     For example, if we have versions 4 and 5 of the model as separate<br>
&gt;     &gt;     artifacts, then we can generate &quot;V4Vm&quot; and &quot;V5Vm&quot; entity classes, and<br>
&gt;     &gt;     &quot;V4VmService&quot; and &quot;V5VmService&quot; service classes. These can be used<br>
&gt;     &gt;     simultaneously in the server, so we can have in the same engine<br>
&gt;     &gt;     implementations for multiple versions.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; There are also many ways to do that. Here [7] is a pretty clean way to<br>
&gt;     &gt; do it with jax-rs and you will have everything related in one resource.<br>
&gt;     &gt;<br>
&gt;<br>
&gt;     Yes, there are many ways. In my opinion it is better to use the HTTP<br>
&gt;     &quot;Version&quot; header, and to forward requests to different resource<br>
&gt;     implementations without requiring different URLs or different<br>
&gt;     content types.<br>
&gt;<br>
&gt; Have no strong opinion there, just seemed to be a good choice regarding<br>
&gt; to versioning limitations in jax-rs and our use of jax-rs subresources.<br>
&gt;<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     The final picture isn&#39;t completely defined yet.<br>
&gt;     &gt;<br>
&gt;     &gt;     Regards,<br>
&gt;     &gt;     Juan Hernandez<br>
&gt;     &gt;<br>
&gt;     &gt;     &gt; On Mon, Oct 26, 2015 at 4:03 PM, Juan Hernández &lt;<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;<br>
&gt;     &gt;     &gt; &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a> &lt;mailto:<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>&gt;&gt;&gt;&gt; wrote:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Hello,<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     I will soon merge the following patches that introduce a new<br>
&gt;     &gt;     way to<br>
&gt;     &gt;     &gt;     specify the contracts of the RESTAPI:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;       restapi: Introduce metamodel<br>
&gt;     &gt;     &gt;       <a href="https://gerrit.ovirt.org/45852" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/45852</a><br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;       restapi: Use metamodel<br>
&gt;     &gt;     &gt;       <a href="https://gerrit.ovirt.org/46478" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/46478</a><br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;       restapi: Generate JAX-RS interfaces from model<br>
&gt;     &gt;     &gt;       <a href="https://gerrit.ovirt.org/47337" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/47337</a><br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     &gt; Looks pretty much like we are replacing one way of<br>
&gt;     annotating things<br>
&gt;     &gt;     &gt; with another way of specifying things.<br>
&gt;     &gt;     &gt; Could you elaborate what the benefit of that way of<br>
&gt;     description is?<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; How would I customize endpoints with e.g. @Gzip annotations?<br>
&gt;     Would<br>
&gt;     &gt;     I at<br>
&gt;     &gt;     &gt; the end still have my JAX-RS annotates resource classes?<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     These patches introduce a new &quot;metamodel&quot; concept, and move<br>
&gt;     &gt;     the current<br>
&gt;     &gt;     &gt;     specification of the RESTAPI based on XML schema and JAX-RS<br>
&gt;     &gt;     interfaces<br>
&gt;     &gt;     &gt;     to a new &quot;model&quot; built on the new metamodel.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     What does this mean for you in practical terms?<br>
&gt;     Currently when<br>
&gt;     &gt;     you want<br>
&gt;     &gt;     &gt;     to introduce or modify one of the data types used by the<br>
&gt;     &gt;     RESTAPI you<br>
&gt;     &gt;     &gt;     start by modifying the XML schema. Once the patches are<br>
&gt;     merged<br>
&gt;     &gt;     the XML<br>
&gt;     &gt;     &gt;     schema will never be touched, as it will be automatically<br>
&gt;     &gt;     generated from<br>
&gt;     &gt;     &gt;     the &quot;model&quot;. For example, imagine that you need to add a new<br>
&gt;     &gt;     &quot;color&quot;<br>
&gt;     &gt;     &gt;     attribute to the &quot;VM&quot; entity. To do so with the new<br>
&gt;     model you<br>
&gt;     &gt;     will have<br>
&gt;     &gt;     &gt;     to modify the following file, which is the specification of<br>
&gt;     &gt;     the &quot;Vm&quot;<br>
&gt;     &gt;     &gt;     entity, written as a Java interface:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     <a href="https://gerrit.ovirt.org/#/c/46478/16/backend/manager/modules/restapi/model/src/main/java/types/Vm.java" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/46478/16/backend/manager/modules/restapi/model/src/main/java/types/Vm.java</a><br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     In that interface you will have to add a line like this:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;       String color();<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Note that this Java interface is just the specification<br>
&gt;     of the<br>
&gt;     &gt;     entity,<br>
&gt;     &gt;     &gt;     it won&#39;t be used at all during runtime. Instead of that the<br>
&gt;     &gt;     XML schema<br>
&gt;     &gt;     &gt;     will be generated from it, and then Java will be generated<br>
&gt;     &gt;     from the XML<br>
&gt;     &gt;     &gt;     schema, as we do today (this will change in the future, but<br>
&gt;     &gt;     not yet).<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Same for the services. If you want to add a new &quot;paint&quot;<br>
&gt;     action<br>
&gt;     &gt;     to the<br>
&gt;     &gt;     &gt;     &quot;Vm&quot; resource then you won&#39;t modify the JAX-RS interfaces,<br>
&gt;     &gt;     instead of<br>
&gt;     &gt;     &gt;     that you will modify the following file, which is the<br>
&gt;     &gt;     specification of<br>
&gt;     &gt;     &gt;     the &quot;Vm&quot; service, written as a Java interface:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     <a href="https://gerrit.ovirt.org/#/c/47337/6/backend/manager/modules/restapi/model/src/main/java/services/VmService.java" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/47337/6/backend/manager/modules/restapi/model/src/main/java/services/VmService.java</a><br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     In that interface you will need to add a sub-interface<br>
&gt;     &gt;     representing the<br>
&gt;     &gt;     &gt;     action:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;       interface Paint {<br>
&gt;     &gt;     &gt;       }<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     The JAX-RS interface will be generated from that.<br>
&gt;     Currently these<br>
&gt;     &gt;     &gt;     sub-interfaces are empty. In the future they will<br>
&gt;     contain the<br>
&gt;     &gt;     &gt;     specifications of the parameters (currently in the<br>
&gt;     &gt;     rsdl_metadata.yml<br>
&gt;     &gt;     &gt;     file).<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     These changes will currently affect only the<br>
&gt;     specification of the<br>
&gt;     &gt;     &gt;     RESTAPI, not the implementation, so in in the<br>
&gt;     &gt;     &quot;Backend*Resource&quot; classes<br>
&gt;     &gt;     &gt;     things won&#39;t change yet.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; Currently I do not really understand where we are going<br>
&gt;     here. Are we<br>
&gt;     &gt;     &gt; trying to get rid of rdsl?<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; So basically two questions:<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; 1) What is the final goal?<br>
&gt;     &gt;     &gt; 2) What speaks agains using Hibernate validator on Daos in<br>
&gt;     combination<br>
&gt;     &gt;     &gt; with JAX-RS annotated resources (and just removing all<br>
&gt;     interfaces, as<br>
&gt;     &gt;     &gt; far as I can see we only have one implementation per<br>
&gt;     endpoint) and<br>
&gt;     &gt;     &gt; creating all schemas and clients through SWAGGER tooling?<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     If you have doubts, please let me know.<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     Regards,<br>
&gt;     &gt;     &gt;     Juan Hernandez<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;     --<br>
&gt;     &gt;     &gt;     Dirección Comercial: C/Jose Bardasano Baos, 9, Edif.<br>
&gt;     Gorbea 3,<br>
&gt;     &gt;     planta<br>
&gt;     &gt;     &gt;     3ºD, 28016 Madrid, Spain<br>
&gt;     &gt;     &gt;     Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 -<br>
&gt;     &gt;     Red Hat<br>
&gt;     &gt;     &gt;     S.L.<br>
&gt;     &gt;     &gt;     _______________________________________________<br>
&gt;     &gt;     &gt;     Devel mailing list<br>
&gt;     &gt;     &gt;     <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;<br>
&gt;     &gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a> &lt;mailto:<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>&gt;&gt;&gt;<br>
&gt;     &gt;     &gt;     <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; Thanks,<br>
&gt;     &gt;     &gt;<br>
&gt;     &gt;     &gt; Roman<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;     --<br>
&gt;     &gt;     Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,<br>
&gt;     planta<br>
&gt;     &gt;     3ºD, 28016 Madrid, Spain<br>
&gt;     &gt;     Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 -<br>
&gt;     Red Hat<br>
&gt;     &gt;     S.L.<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; I don&#39;t know if it is the right thing to do to invent something new<br>
&gt;     &gt; here. I personally would prefer to thread a path which is very<br>
&gt;     common on<br>
&gt;     &gt; the java community.<br>
&gt;     &gt; I would love follow the DRY principle regarding to the stack and the<br>
&gt;     &gt; code and would just use the great community projects there.<br>
&gt;     &gt;<br>
&gt;     &gt; It would also completely eliminate any custom magic. The JAX-RS<br>
&gt;     and CDI<br>
&gt;     &gt; magic is pretty standard and easy to understand.<br>
&gt;     &gt; From my perspective, real JAX-RS resoures have the advantage of<br>
&gt;     &gt;<br>
&gt;     &gt;  * being very easy to understand (there is magic, but the<br>
&gt;     connection to<br>
&gt;     &gt; the real endpoint is pretty clear)<br>
&gt;     &gt;  * being easy to customize suff, like adding @GZip to an annotation<br>
&gt;     &gt;  * describing pretty clearly the connection between the generated rest<br>
&gt;     &gt; interface and the internal services<br>
&gt;     &gt;<br>
&gt;     &gt; Finally writing hand crafted tests is also much easier.<br>
&gt;     &gt;<br>
&gt;     &gt; What are your thoughts about that?<br>
&gt;     &gt;<br>
&gt;     &gt; Best Regards,<br>
&gt;     &gt; Roman<br>
&gt;     &gt;<br>
&gt;     &gt;<br>
&gt;     &gt; [1] <a href="https://github.com/rmohr/jetty-maven-cdi-demo" rel="noreferrer" target="_blank">https://github.com/rmohr/jetty-maven-cdi-demo</a><br>
&gt;     &gt; [2]<br>
&gt;     &gt;<br>
&gt;     <a href="https://github.com/rmohr/jetty-maven-cdi-demo/blob/master/src/main/java/rmohr/examples/cdi/MyDto.java" rel="noreferrer" target="_blank">https://github.com/rmohr/jetty-maven-cdi-demo/blob/master/src/main/java/rmohr/examples/cdi/MyDto.java</a><br>
&gt;     &gt; [3] <a href="http://swagger.io/" rel="noreferrer" target="_blank">http://swagger.io/</a><br>
&gt;     &gt; [4] <a href="https://github.com/kongchen/swagger-maven-plugin" rel="noreferrer" target="_blank">https://github.com/kongchen/swagger-maven-plugin</a><br>
&gt;     &gt; [5] <a href="https://github.com/swagger-api/swagger-codegen" rel="noreferrer" target="_blank">https://github.com/swagger-api/swagger-codegen</a><br>
&gt;     &gt; [6]<br>
&gt;     &gt;<br>
&gt;     <a href="https://github.com/rmohr/jetty-maven-cdi-demo/blob/master/src/main/java/rmohr/examples/cdi/RestSubResource.java" rel="noreferrer" target="_blank">https://github.com/rmohr/jetty-maven-cdi-demo/blob/master/src/main/java/rmohr/examples/cdi/RestSubResource.java</a><br>
&gt;     &gt; [7]<br>
&gt;     &gt;<br>
&gt;     <a href="http://maxenglander.com/2013/04/23/basic-restful-api-versioning-in-jersey.html" rel="noreferrer" target="_blank">http://maxenglander.com/2013/04/23/basic-restful-api-versioning-in-jersey.html</a><br>
&gt;     &gt; [8] <a href="https://github.com/swagger-api/swagger-ui" rel="noreferrer" target="_blank">https://github.com/swagger-api/swagger-ui</a><br>
&gt;     &gt;<br>
&gt;<br>
&gt; [9]<br>
&gt; <a href="https://github.com/swagger-api/swagger-core/blob/master/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/Reader.java" rel="noreferrer" target="_blank">https://github.com/swagger-api/swagger-core/blob/master/modules/swagger-jaxrs/src/main/java/io/swagger/jaxrs/Reader.java</a><br>
&gt;<br>
<br>
--<br>
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta<br>
3ºD, 28016 Madrid, Spain<br>
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.<br>
</div></div></blockquote></div><br></div></div>