<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 27, 2015 at 2:41 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 02:10 PM, Roman Mohr wrote:<br>
><br>
><br>
> On Tue, Oct 27, 2015 at 1:45 PM, 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 12:55 PM, Roman Mohr wrote:<br>
> ><br>
> ><br>
> > On Tue, Oct 27, 2015 at 12:16 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>
> > 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> <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>
</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>><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>
> > > 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>
> <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>>>><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>><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>
</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<br>
> clean and<br>
> > nice.<br>
> > > > > I would love to read a few words about the big<br>
> > picture. What<br>
> > > is the<br>
> > > > > final scenario?<br>
> > > > ><br>
> > > ><br>
> > > > The motivation for this change is that currently we<br>
> > don't have<br>
> > > a central<br>
> > > > place where the RESTAPI is specified, rather we<br>
> 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<br>
> (without the<br>
> > > parameters).<br>
> > > > * rsdl_metadata.yaml for the parameters of the<br>
> > operational model.<br>
> > > ><br>
> > > > This makes it difficult to infer information about the<br>
> > model. For<br>
> > > > example, the generators of the SDKs have to<br>
> download the XML<br>
> > > schema, and<br>
> > > > the RSDL (which is generated from the JAX-RS<br>
> interfaces<br>
> > 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<br>
> extract<br>
> > > what they<br>
> > > > need.<br>
> > > ><br>
> > > > Same happens with the CLI: it has to extract the<br>
> information<br>
> > > it needs<br>
> > > > from the Python code generated for the Python SDK, yet<br>
> > another<br>
> > > level of<br>
> > > > indirection.<br>
> > > ><br>
> > > ><br>
> > > > You are right, that definitely needs to be cleaned up. I<br>
> > just want to<br>
> > > > discuss a few points below with you.<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > We are also lacking a comprehensive reference<br>
> > documentation of the<br>
> > > > RESTAPI. What we currently have has been written by<br>
> > 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<br>
> > purpose.<br>
> > > > I created a demo in [1] which uses resteasy, weld,<br>
> > 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<br>
> > documentation<br>
> > > in a<br>
> > > > more human readable way.<br>
> > > ><br>
> > ><br>
> > > Yes, I considered Swagger, and rejected it because it is<br>
> JSON<br>
> > centric,<br>
> > > and I think JSON isn't as good as Java to represent the<br>
> > contracts of our<br>
> > > RESTAPI.<br>
> > ><br>
> > ><br>
> > > You just write plain jax-rs, swagger just creates a<br>
> description out of<br>
> > > it. So the source defining the contract is pure java<br>
> (jax-rs with<br>
> > some<br>
> > > swagger annotations for description, etc.).<br>
> > > Or am I missing the point here?<br>
> > ><br>
> ><br>
> > If I understand correctly the Swagger core is a JSON (or YAML)<br>
> > specification of the API. From that you can generate JAX-RS<br>
> annotated<br>
> > code, not the other way around. So the specification document<br>
> that you<br>
> > write is a JSON document.<br>
> ><br>
> ><br>
> > You are right, my terminology here was not clear. Swagger is just a<br>
> > specification. Swagger-core and swagger-jaxrs are the ones which can<br>
> > create the documnetation out of JAX-RS resources.<br>
> ><br>
> ><br>
> > Alternatively, you can use the Swagger annotations to decorate<br>
> 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<br>
> where we<br>
> > are today, and it causes multiple problems. I think it is<br>
> better to have<br>
> > the specification and the implementation separate. Swagger<br>
> does that<br>
> > well when using JSON directly, our metamodel also does it<br>
> well, but<br>
> > using a better language.<br>
> ><br>
> ><br>
> ><br>
> > Isn't our problem that we have everything scattered arount the<br>
> place and<br>
> > not that we are using JAX-RS? I don't think that this has anything<br>
> to do<br>
> > with specification before implementation or implementation before<br>
> > specification.<br>
> ><br>
><br>
> Correct, the problem with the specification if that we don't have one,<br>
> just pieces of it scattered around, some in the XML schema, some in the<br>
> JAX-RS interfaces, some in the rsdl_metadata.yaml file.<br>
><br>
> This is historically related with the order of specification and<br>
> implementation. When the project started we didn't create a<br>
> specification of the RESTAPI, only an implementation, using JAX-RS and<br>
> XML schema. Then we added the rsdl_metadata.yaml file, and extracted a<br>
> specification from that, the RSDL. The result is hard to consume. To<br>
> make it easy to consume we need to reverse the order: first<br>
> specification, free of implementation details, then implementation.<br>
><br>
> ><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>
> > 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.<br>
> ><br>
> ><br>
> > You can just create the entities/daos once like we do now on every build<br>
> > and annotate them once and drop the whole xml.<br>
> ><br>
><br>
> The DAOs aren't part of the RESTAPI. The backend entities aren't either.<br>
> The RESTAPI has its own entities which are currently generated from XML<br>
> schema.<br>
><br>
><br>
> s/DAOs/DTOs I meant Data transfer object, not Data Access objects. And<br>
> they are generated.<br>
><br>
><br>
><br>
> ><br>
> > Where do we put<br>
> > the documentation then? Part in the JAX-RS interfaces, part in the XML<br>
> > schema.<br>
> ><br>
> ><br>
> > I don't understand that. There is only one documentation and<br>
> > implementation source, that is the JAX-RS resource and the entity/dao<br>
> > accepted by the endpoint.<br>
> > The XML schema can just be removed. The documentation in swagger format<br>
> > for other tools like swagger-codegen and swagger-ci can be made<br>
> > available through swagger-maven-plugin or a servlet in the engine which<br>
> > generates the swagger json on the fly (like I did in [1])<br>
> ><br>
><br>
> Those are two: JAX-RS and entities, and they are implementations, not<br>
> specifications.<br>
><br>
> The XML schema can't be drop, as many clients use it. But we can<br>
> generate it from the model, and that is what we will do.<br>
><br>
><br>
> Did not look into that.<br>
><br>
><br>
><br>
> ><br>
> > 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<br>
> our own<br>
> > metamodel.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > ><br>
> > ><br>
> > > Swagger UI is certainly great. I did test it and it is<br>
> really<br>
> > good. We<br>
> > > may be able to copy some concepts.<br>
> > ><br>
> > > ><br>
> > > ><br>
> > > > To solve these issues I intend to have the<br>
> specification of<br>
> > > the RESTAPI<br>
> > > > only in one place, and using only one technology. I<br>
> > decided to<br>
> > > use Java<br>
> > > > interfaces for that. Note however that they are<br>
> just the<br>
> > > support for the<br>
> > > > information, like paper is the support for ink. I<br>
> decided to<br>
> > > use Java<br>
> > > > because it is easy to create, modify and re-factor<br>
> using<br>
> > tools<br>
> > > familiar<br>
> > > > to most of us.<br>
> > > ><br>
> > > > These source of these interfaces is analysed<br>
> (using QDox,<br>
> > > currently) and<br>
> > > > a "model" of the RESTAPI is generated in memory. This<br>
> > 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<br>
> > 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<br>
> part of<br>
> > a web<br>
> > > > application that provides comprehensive reference<br>
> > documentation,<br>
> > > > assuming that we dedicate the time to write<br>
> documentation<br>
> > > comments in<br>
> > > > the specification.<br>
> > > ><br>
> > > > I intend to use this model also to do simplify the<br>
> > generators<br>
> > > of the<br>
> > > > SDKs and the CLI.<br>
> > > ><br>
> > > > In addition these are some of the things that I would<br>
> > like to<br>
> > > change in<br>
> > > > the near future (for 4.0):<br>
> > > ><br>
> > > > * Move the specification of the parameters of<br>
> operations out<br>
> > > of the<br>
> > > > rsdl_metadata.yaml file and into the model. For<br>
> 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<br>
> > received<br>
> > > > * as parameter, and the representation of<br>
> 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<br>
> 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<br>
> 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<br>
> constraints<br>
> > > are in the<br>
> > > > model, then we can just check them and reject requests<br>
> > before<br>
> > > delivering<br>
> > > > them to the application. Currently we do this manually<br>
> > (and often<br>
> > > > forget) with calls to "validate(...)" methods.<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > Did you consider just annotating the DTOs with JSR-303<br>
> > 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<br>
> > isn't to<br>
> > > implement it, rather to specify it. Using annotations in<br>
> this<br>
> > way won't<br>
> > > help the generators of the SDKs, for example, to figure<br>
> out what<br>
> > > parameters are required, mandatory, etc.<br>
> > ><br>
> > ><br>
> > > Swagger understands them. From my example project, swagger<br>
> created<br>
> > 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,<br>
> > python, ...<br>
> > ><br>
> ><br>
> > This is extracting the specification from the implementation,<br>
> which<br>
> > isn't correct in my opinion, it should be the opposite. Not<br>
> saying that<br>
> > this makes Swagger bad, it is nice that it has this<br>
> capability, but I<br>
> > think we can do it better.<br>
> ><br>
> ><br>
> > In my opition this is the main advantage of that. It is DRY while<br>
> still<br>
> > having full control of the implementation.<br>
> ><br>
><br>
> I think that DRY is better served if you write the specification once,<br>
> and then, from that, you generate the contracts (interfaces, entities,<br>
> builders, etc) that the implementation should use.<br>
><br>
><br>
> And how do you add special things like @Gzip or other specializations<br>
> which you might use?<br>
><br>
<br>
</div></div>There shouldn't be any specialization. All the RESTAPI services should<br>
behave exactly the same. So if one of them supports GZIP, for example,<br>
then all of the should do.<br>
<br>
Anyhow, if there is a real need for a specialization it can go into the<br>
implementation, it isn't a problem.<br>
<div><div class="h5"><br>
><br>
><br>
> ><br>
> > > ><br>
> > > ><br>
> > > > * Generate the Java classes directly from the<br>
> model. Instead of Model -><br>
> > > > XML Schema -> Java, we can do Model -> Java. This<br>
> will allow us to solve<br>
> > > > some of the XJC compiler limitations, like the<br>
> horrible way we handle<br>
> > > > arrays today.<br>
> > > ><br>
> > > ><br>
> > > > Swagger [3] is a rest documentation specification.<br>
> There is also a maven<br>
> > > > plugin [4] and you can create clients for example with<br>
> [5].<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > * Replace JAX-RS with a simpler infrastructure<br>
> that supports better<br>
> > > > streaming and CDI injection.<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > With resteasy-cdi you have pretty good injection<br>
> support for resteasy.<br>
> > > > Run the demo in [1] to see it in action and look at<br>
> the file at [6].<br>
> > > ><br>
> > ><br>
> > > Resteasy-CDI isn't standard, it only works with<br>
> 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<br>
> 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<br>
> containers. I<br>
> > > don't think that this is an argument.<br>
> > ><br>
> ><br>
> > Well, nobody thought that JBoss would drop Tomcat, and they<br>
> did. Nobody<br>
> > thought that Resteasy would change the SPI from 2.x to 3.x,<br>
> and they<br>
> > did.\<br>
> ><br>
> ><br>
> > It will be there for the next year or another library which offers the<br>
> > same thing. Having injections in Jax-rs resources is important for<br>
> > spring, jboss, glassfish and others there will always be ways to do<br>
> > that. I don't know why we should create our own 'custom standard' just<br>
> > because another standard does not include dependency injection when we<br>
> > can just extend it so easily.<br>
> ><br>
><br>
> Here our views of "easily" are different. I have suffered the problems<br>
> with changes in Resteasy over the past years, and I won't describe it as<br>
> easy.<br>
><br>
><br>
> I agree. Maven and dependencies are never easy. But I prefer to fix<br>
> something now and then on regular maven dependency updates than being<br>
> tied to somesing because of a custom code generator.<br>
><br>
><br>
> ><br>
> > We want (well, I want) to get out of JAX-RS because it doesn't support<br>
> > well CDI and streaming.<br>
> ><br>
> ><br>
> > Why should streaming resources be in the rest interface?<br>
> ><br>
><br>
> Streaming should be used not only in the RESTAPI, but in the complete<br>
> system, including the backend and the DAL, otherwise we have serious<br>
> problems when clients requests large amounts of objects.<br>
><br>
><br>
> Streaming is no solution here. It does not address the problem at all.<br>
> Solving the database bottleneck with this approach is just wrong.<br>
> A client can iterate over our 10000 VMs extremely fast. No matter if<br>
> streamed or not, so this will still hit the database.<br>
><br>
<br>
</div></div>Streaming is a mechanism to improve the latency when serving multiple<br>
objects: instead of having your client waiting till you have all the<br>
requested objects (10 or 10K) in memory you send them as soon as you<br>
can. In addition it also reduces the use of memory in the server.<br>
<br>
Think about watching a movie. What is better, downloading it complete<br>
and the watch it, or watch as the individual frames arrive?<br>
<span class=""><br></span></blockquote><div>Don't forget that movies are stored in form which is meant to be streamed. This is not the case when fetching data from databases.<br></div><div>Also message brokers use leveldb or other file systems if they have to store something for persistence reasons, which are basically created for streaming.<br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> What you normally do to prevent this:<br>
><br>
> 1) A second level cache (see here for a start<br>
> <a href="https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:cache" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:cache</a>)<br>
<br>
</span>Second level cache doesn't solve the latency problem. If someone<br>
requests 1000 VMs he will still have to wait till you have the 1000 VMs<br>
arranged in memory before sending them.<br>
<span class=""><br>
> 2) Add paging to the rest interface and define a maximum number per<br>
> page (would you trottle the stream in your approach per session, request?)<br>
><br>
> The client then just happily fetch one page after the other without<br>
> thinking about overloading your system (but of course the client can<br>
> still deliberately harm you), because a client can assume that you<br>
> optimize your application (caches, daos and database and page size per<br>
> request) for that.<br>
><br>
<br>
</span>The RESTAPI already has a pagination mechanism, but some clients don't<br>
want to use it. We used to have a hard limit and we had to remove it.<br>
<span class=""><br>
> Of course for notifications streams are great, but again why should they<br>
> be in the rest interface? Adding websockets or other stuff to listen on<br>
> changed VMs would be great. Just discussed this recently with rgolan.<br>
><br>
<br>
</span>Notifications are currently out of the scope of the RESTAPI, and there<br>
are no plans to add them.<br>
<span class=""><br>
><br>
> Think, for example, that a client requests 100 virtual machines. What we<br>
> currently do is the following:<br>
><br>
> * The DAL requests the 100 rows to the database, and waits till the 100<br>
> rows are loaded in memory (this is how the JDBC driver works by<br>
> default). Only when the 100 rows are in memory the are converted to<br>
> backend objects.<br>
><br>
> * The DAL returns the 100 backend objects to the BLL, which processes<br>
> them. Only when they are all processed they are returned to the RESTAPI,<br>
> as a list.<br>
><br>
> * The RESTAPI transforms the 100 backend objects into RESTAPI objects.<br>
> Only when the are all transformed they are returned by the corresponding<br>
> JAX-RS method to the JAX-RS infrastructure. This is encouraged by the<br>
> high level interface of JAX-RS, as it encourages you to write methods<br>
> like this:<br>
><br>
> @GET<br>
> Vms get()<br>
><br>
> Who could ever have thought that this can be a good idea. :D<br>
> I would go with paging instead of streams for that purpose (just make<br>
> sure to sort the returned values repeatable).<br>
><br>
<br>
</span>This is just what JAX-RS encourages.<br>
<span class=""><br>
><br>
> * Once the JAX-RS infrastructure has the complete result it starts to<br>
> convert it to the XML (or JSON) document.<br>
><br>
> Same for the reverse direction.<br>
><br>
> Put 10K virtual machines instead of just 100 and you see the problem.<br>
><br>
> Of course one could use JAX-RS in a way that doesn't have this problem,<br>
> it is certainly possible, you can get the output stream and serialize<br>
> the result from the resource implementation, in a an streaming fashion.<br>
> But then the value of JAX-RS is reduced, you can do the same with a<br>
> simpler servlet architecture. That is what I plan to do.<br>
><br>
><br>
> Exactly my point. I would do monitoring stuff with different simple<br>
> stream servlets.<br>
><br>
<br>
</span>Yes, servlet technology is enough and better for that, and for serving<br>
the RESTAPI content as well.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
><br>
> ><br>
> > ><br>
> > > ><br>
> > > ><br>
> > > > * Add support for multiple versions of the API, using<br>
> > the "Version"<br>
> > > > header, and generating different Java classes for<br>
> > entities and services.<br>
> > > > For example, if we have versions 4 and 5 of the<br>
> model as<br>
> > separate<br>
> > > > artifacts, then we can generate "V4Vm" and "V5Vm"<br>
> entity<br>
> > classes, and<br>
> > > > "V4VmService" and "V5VmService" service classes. These<br>
> > can be used<br>
> > > > simultaneously in the server, so we can have in<br>
> the same<br>
> > engine<br>
> > > > implementations for multiple versions.<br>
> > > ><br>
> > > ><br>
> > > > There are also many ways to do that. Here [7] is a pretty<br>
> > clean way to<br>
> > > > do it with jax-rs and you will have everything related in<br>
> > one resource.<br>
> > > ><br>
> > ><br>
> > > Yes, there are many ways. In my opinion it is better to use<br>
> > the HTTP<br>
> > > "Version" header, and to forward requests to different<br>
> resource<br>
> > > implementations without requiring different URLs or<br>
> different<br>
> > > content types.<br>
> > ><br>
> > > Have no strong opinion there, just seemed to be a good choice<br>
> > regarding<br>
> > > to versioning limitations in jax-rs and our use of jax-rs<br>
> > 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<br>
> > <<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>>>><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>><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><br>
> <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>>>><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>><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<br>
> > 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<br>
> > annotations?<br>
> > > Would<br>
> > > > I at<br>
> > > > > the end still have my JAX-RS annotates resource<br>
> classes?<br>
> > > > ><br>
> > > > ><br>
> > > > > These patches introduce a new "metamodel"<br>
> concept,<br>
> > and move<br>
> > > > the current<br>
> > > > > specification of the RESTAPI based on XML schema<br>
> > 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<br>
> used<br>
> > by the<br>
> > > > RESTAPI you<br>
> > > > > start by modifying the XML schema. Once the<br>
> > patches are<br>
> > > merged<br>
> > > > the XML<br>
> > > > > schema will never be touched, as it will be<br>
> > automatically<br>
> > > > generated from<br>
> > > > > the "model". For example, imagine that you<br>
> need to<br>
> > add a new<br>
> > > > "color"<br>
> > > > > attribute to the "VM" entity. To do so with<br>
> the new<br>
> > > model you<br>
> > > > will have<br>
> > > > > to modify the following file, which is the<br>
> > specification of<br>
> > > > the "Vm"<br>
> > > > > entity, written as a Java interface:<br>
> > > > ><br>
> > > > ><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<br>
> line like<br>
> > this:<br>
> > > > ><br>
> > > > > String color();<br>
> > > > ><br>
> > > > > Note that this Java interface is just the<br>
> > specification<br>
> > > of the<br>
> > > > entity,<br>
> > > > > it won't be used at all during runtime.<br>
> Instead of<br>
> > that the<br>
> > > > XML schema<br>
> > > > > will be generated from it, and then Java will be<br>
> > generated<br>
> > > > from the XML<br>
> > > > > schema, as we do today (this will change in the<br>
> > future, but<br>
> > > > not yet).<br>
> > > > ><br>
> > > > > Same for the services. If you want to add a new<br>
> > "paint"<br>
> > > action<br>
> > > > to the<br>
> > > > > "Vm" resource then you won't modify the JAX-RS<br>
> > interfaces,<br>
> > > > instead of<br>
> > > > > that you will modify the following file,<br>
> which is the<br>
> > > > specification of<br>
> > > > > the "Vm" service, written as a Java interface:<br>
> > > > ><br>
> > > > ><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<br>
> sub-interface<br>
> > > > representing the<br>
> > > > > action:<br>
> > > > ><br>
> > > > > interface Paint {<br>
> > > > > }<br>
> > > > ><br>
> > > > > The JAX-RS interface will be generated from<br>
> that.<br>
> > > Currently these<br>
> > > > > sub-interfaces are empty. In the future they<br>
> will<br>
> > > contain the<br>
> > > > > specifications of the parameters (currently<br>
> 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<br>
> 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<br>
> on Daos in<br>
> > > combination<br>
> > > > > with JAX-RS annotated resources (and just<br>
> 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<br>
> 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,<br>
> 9, Edif.<br>
> > > Gorbea 3,<br>
> > > > planta<br>
> > > > > 3ºD, 28016 Madrid, Spain<br>
> > > > > Inscrita en el Reg. Mercantil de Madrid – C.I.F.<br>
> > 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>
> > > <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>
> <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>
> > <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>
> <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.<br>
> > Gorbea 3,<br>
> > > planta<br>
> > > > 3ºD, 28016 Madrid, Spain<br>
> > > > Inscrita en el Reg. Mercantil de Madrid – C.I.F.<br>
> 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<br>
> > something new<br>
> > > > here. I personally would prefer to thread a path which<br>
> is very<br>
> > > common on<br>
> > > > the java community.<br>
> > > > I would love follow the DRY principle regarding to the<br>
> stack<br>
> > and the<br>
> > > > code and would just use the great community projects<br>
> there.<br>
> > > ><br>
> > > > It would also completely eliminate any custom magic.<br>
> 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<br>
> 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<br>
> > annotation<br>
> > > > * describing pretty clearly the connection between the<br>
> > 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>
> > ><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>
> > ><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>
> > ><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>
> > ><br>
> ><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>
<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>