<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 23, 2017 at 5:06 PM 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/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 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 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 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 `Accept:<br>
> application/octet-stream`.<br>
> * The server can be started with port 0. This way you are 100% sure<br>
> that it will start using a unique port without colliding with any<br>
> other service.<br>
><br>
How can the client now the port number, then? Is the actual port 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 before.<br>
><br>
Did it return 404? What's on that page? Do we expose keys/values/entries<br>
anywhere in the REST endpoint?<br></blockquote><div><br></div><div>Exactly. You may try it using our Docker image and invoking something like this: curl -v -u user:changeme <a href="http://172.17.0.6:8080/rest">http://172.17.0.6:8080/rest</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> * UTF-8 charset is now the default. You may always ask the server to<br>
> return different encoding using Accept header. The charset is not<br>
> returned with binary mime types.<br>
> * If a HEAD request results in an error, a message will be returned<br>
> to the client. Even though this behavior breaks Commons HTTP<br>
> Client (HEAD requests are handled slightly differently and 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 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 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 delta-updating<br>
entries with Content-Range on PUTs?<br></blockquote><div><br></div><div>No and AFAK there are no plans to do it (but perhaps Tristan could shed some more light onto this). We could use HTTP PATCH for delta updates...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* For PUTs/POSTs, do we return 200/201/204 according to the spec?<br>
(modified/created/modified)<br></blockquote><div><br></div><div>No, I decided to leave it as 200 for compatibility reasons. But I agree, we could change this as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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 DELETE<br>
return the prev entity (it should return 200 & entity or 204 and no<br>
response)<br></blockquote><div><br></div><div>Yes, PUT replaces previous value [1] if such exists (whereas POST would return a conflict). If for some reason you can not replace current value, you will get a preconditions failed error.</div><div><br></div><div>[1] <a href="https://github.com/infinispan/infinispan/pull/5094/files#diff-58f67698080cc0242320614c921559a8R301">https://github.com/infinispan/infinispan/pull/5094/files#diff-58f67698080cc0242320614c921559a8R301</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Do we handle OPTIONS in any way?<br></blockquote><div><br></div><div>No. Do we need it? I haven't seen any real implementation that uses that for discovering REST operations.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
> <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>