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