<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 25, 2017 at 7:42 AM Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/24/2017 10:44 AM, Sebastian Laskawiec wrote:<br>
><br>
><br>
> On Tue, May 23, 2017 at 5:06 PM Radim Vansa <<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a><br>
> <mailto:<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>>> wrote:<br>
><br>
> On 05/16/2017 11:05 AM, Sebastian Laskawiec wrote:<br>
> > Hey guys!<br>
> ><br>
> > I'm working on REST Server refactoring and I changed some of the<br>
> > previous behavior. Having in mind that we are implementing this in a<br>
> > minor release, I tried to make those changes really cosmetic:<br>
> ><br>
> > * RestEASY as well as Servlet API have been removed from<br>
> modules and<br>
> > BOM. If your app relied on it, you'll need to specify them<br>
> > separately in your pom.<br>
> > * Previous implementation picked application/text as a default<br>
> > content type. I replaced it with text/plain with charset<br>
> which is<br>
> > more precise and seems to be more widely adopted.<br>
> > * Putting an entry without any TTL nor Idle Time made it living<br>
> > forever (which was BTW aligned with the docs). I switched to<br>
> > server configured defaults in this case. If you want to have an<br>
> > entry that lives forever, just specify 0 or -1 there.<br>
> > * Requesting an entry with wrong mime type (imagine it was stored<br>
> > using application/octet-stream and now you're requesting<br>
> > text/plain) cased Bad Request. Now I switched it to Not<br>
> Acceptable<br>
> > which was designed specially to cover this type of use case.<br>
> > * In compatibility mode the server often tried to "guess" the<br>
> > mimetype (the decision was often between text/plain and<br>
> > application/octet-stream). I honestly think it was a wrong move<br>
> > and made the server side code very hard to read and predict what<br>
> > would be the result. Now the server always returns text/plain by<br>
> > default. If you want to get a byte stream back, just add<br>
> `Accept:<br>
> > application/octet-stream`.<br>
> > * The server can be started with port 0. This way you are 100%<br>
> sure<br>
> > that it will start using a unique port without colliding<br>
> with any<br>
> > other service.<br>
> ><br>
> How can the client now the port number, then? Is the actual port<br>
> exposed<br>
> through JMX?<br>
><br>
> > * The REST server hosts HTML page if queried using GET on default<br>
> > context. I think it was a bug that it didn't work correctly<br>
> before.<br>
> ><br>
> Did it return 404? What's on that page? Do we expose<br>
> keys/values/entries<br>
> anywhere in the REST endpoint?<br>
><br>
><br>
> Exactly. You may try it using our Docker image and invoking something<br>
> like this: curl -v -u user:changeme <a href="http://172.17.0.6:8080/rest" rel="noreferrer" target="_blank">http://172.17.0.6:8080/rest</a><br>
><br>
><br>
> > * UTF-8 charset is now the default. You may always ask the<br>
> server to<br>
> > return different encoding using Accept header. The charset<br>
> is not<br>
> > returned with binary mime types.<br>
> > * If a HEAD request results in an error, a message will be<br>
> returned<br>
> > to the client. Even though this behavior breaks Commons HTTP<br>
> > Client (HEAD requests are handled slightly differently and<br>
> causes<br>
> > the client to hang if a payload is returned), I think it's<br>
> > beneficial to tell the user what went wrong. It's worth to<br>
> mention<br>
> > that Jetty/Netty HTTP clients work correctly.<br>
> > * RestServer doesn't implement Lifecycle now. The protocol server<br>
> > doesn't support start() method without any arguments. You always<br>
> > need to specify configuration + Embedded Cache Manager.<br>
> ><br>
> > Even though it's a long list, I think all those changes were<br>
> worth it.<br>
> > Please let me know if you don't agree.<br>
><br>
> Couple of other questions:<br>
><br>
> * do we accept GET with Range header on keys? What about<br>
> delta-updating<br>
> entries with Content-Range on PUTs?<br>
><br>
><br>
> No and AFAK there are no plans to do it (but perhaps Tristan could<br>
> shed some more light onto this). We could use HTTP PATCH for delta<br>
> updates...<br>
><br>
> * For PUTs/POSTs, do we return 200/201/204 according to the spec?<br>
> (modified/created/modified)<br>
><br>
><br>
> No, I decided to leave it as 200 for compatibility reasons. But I<br>
> agree, we could change this as well.<br>
<br>
Compatibility reasons? You mean compatibility with clients not adhering<br>
to spec? (clients should accept any 2xy as success by definition).<br></blockquote><div><br></div><div>+1, created <a href="https://issues.jboss.org/browse/ISPN-7859">https://issues.jboss.org/browse/ISPN-7859</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> * Do we have any way to execute a replace (or the other prev-value<br>
> returning ops) through REST using single request? For example let<br>
> DELETE<br>
> return the prev entity (it should return 200 & entity or 204 and no<br>
> response)<br>
><br>
><br>
> Yes, PUT replaces previous value [1] if such exists (whereas POST<br>
> would return a conflict). If for some reason you can not replace<br>
> current value, you will get a preconditions failed error.<br>
<br>
I have misformulated the question. I meant to ask if there is a way to<br>
return the previous value when you've replaced it?<br></blockquote><div><br></div><div>Unfortunately no. And there wasn't in previous REST implementation as far as I know.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
><br>
> [1]<br>
> <a href="https://github.com/infinispan/infinispan/pull/5094/files#diff-58f67698080cc0242320614c921559a8R301" rel="noreferrer" target="_blank">https://github.com/infinispan/infinispan/pull/5094/files#diff-58f67698080cc0242320614c921559a8R301</a><br>
<br>
Looking into the code, without considering performance at all, I think<br>
that you've become too ecstatic about Optionals. These should be used as<br>
return types for methods, not a) parameters to methods nor b) fields.<br>
This is a misuse of the API, according to the authors of Optionals in<br>
JDK. Most of the time, you're not using optionals to have fluent chain<br>
of method invocations, so -100 to that.<br></blockquote><div><br></div><div>Answered in "To Optional or not to Optional thread".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> * Do we handle OPTIONS in any way?<br>
><br>
><br>
> No. Do we need it? I haven't seen any real implementation that uses<br>
> that for discovering REST operations.<br>
><br>
><br>
> Radim<br>
><br>
> ><br>
> > Thanks,<br>
> > Sebastian<br>
> ><br>
> > --<br>
> ><br>
> > SEBASTIANŁASKAWIEC<br>
> ><br>
> > INFINISPAN DEVELOPER<br>
> ><br>
> > Red HatEMEA <<a href="https://www.redhat.com/" rel="noreferrer" target="_blank">https://www.redhat.com/</a>><br>
> ><br>
> > <<a href="https://red.ht/sig" rel="noreferrer" target="_blank">https://red.ht/sig</a>><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > infinispan-dev mailing list<br>
> > <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
><br>
> --<br>
> Radim Vansa <<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a> <mailto:<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>>><br>
> JBoss Performance Team<br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
> --<br>
><br>
> SEBASTIANŁASKAWIEC<br>
><br>
> INFINISPAN DEVELOPER<br>
><br>
> Red HatEMEA <<a href="https://www.redhat.com/" rel="noreferrer" target="_blank">https://www.redhat.com/</a>><br>
><br>
> <<a href="https://red.ht/sig" rel="noreferrer" target="_blank">https://red.ht/sig</a>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
--<br>
Radim Vansa <<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>><br>
JBoss Performance Team<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><p class="inbox-inbox-fullname-container" style="box-sizing:border-box;color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span class="inbox-inbox-firstname-container" style="box-sizing:border-box">SEBASTIAN</span><span class="inbox-inbox-Apple-converted-space"> </span><span class="inbox-inbox-lastname-container" style="box-sizing:border-box">ŁASKAWIEC</span></p><p class="inbox-inbox-position-container" style="box-sizing:border-box;color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span class="inbox-inbox-position" style="box-sizing:border-box">INFINISPAN DEVELOPER</span></p><p class="inbox-inbox-legal-container" style="box-sizing:border-box;font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a class="inbox-inbox-redhat-anchor" href="https://www.redhat.com/" target="_blank" style="box-sizing:border-box;color:rgb(0,136,206);margin:0px;text-decoration:none">Red Hat<span class="inbox-inbox-Apple-converted-space"> </span><span style="box-sizing:border-box">EMEA</span></a></p><table border="0" style="box-sizing:border-box;color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody style="box-sizing:border-box"><tr style="box-sizing:border-box"><td width="100px" style="box-sizing:border-box"><a href="https://red.ht/sig" style="box-sizing:border-box"><img width="90" height="auto" style="box-sizing: border-box;" src="https://www.redhat.com/files/brand/email/sig-redhat.png"></a></td></tr></tbody></table></div></div>