On 05/24/2017 10:44 AM, Sebastian Laskawiec wrote: > > > On Tue, May 23, 2017 at 5:06 PM Radim Vansa <rva...@redhat.com > <mailto:rva...@redhat.com>> wrote: > > On 05/16/2017 11:05 AM, Sebastian Laskawiec wrote: > > Hey guys! > > > > I'm working on REST Server refactoring and I changed some of the > > previous behavior. Having in mind that we are implementing this in a > > minor release, I tried to make those changes really cosmetic: > > > > * RestEASY as well as Servlet API have been removed from > modules and > > BOM. If your app relied on it, you'll need to specify them > > separately in your pom. > > * Previous implementation picked application/text as a default > > content type. I replaced it with text/plain with charset > which is > > more precise and seems to be more widely adopted. > > * Putting an entry without any TTL nor Idle Time made it living > > forever (which was BTW aligned with the docs). I switched to > > server configured defaults in this case. If you want to have an > > entry that lives forever, just specify 0 or -1 there. > > * Requesting an entry with wrong mime type (imagine it was stored > > using application/octet-stream and now you're requesting > > text/plain) cased Bad Request. Now I switched it to Not > Acceptable > > which was designed specially to cover this type of use case. > > * In compatibility mode the server often tried to "guess" the > > mimetype (the decision was often between text/plain and > > application/octet-stream). I honestly think it was a wrong move > > and made the server side code very hard to read and predict what > > would be the result. Now the server always returns text/plain by > > default. If you want to get a byte stream back, just add > `Accept: > > application/octet-stream`. > > * The server can be started with port 0. This way you are 100% > sure > > that it will start using a unique port without colliding > with any > > other service. > > > How can the client now the port number, then? Is the actual port > exposed > through JMX? > > > * The REST server hosts HTML page if queried using GET on default > > context. I think it was a bug that it didn't work correctly > before. > > > Did it return 404? What's on that page? Do we expose > keys/values/entries > anywhere in the REST endpoint? > > > Exactly. You may try it using our Docker image and invoking something > like this: curl -v -u user:changeme http://172.17.0.6:8080/rest > > > > * UTF-8 charset is now the default. You may always ask the > server to > > return different encoding using Accept header. The charset > is not > > returned with binary mime types. > > * If a HEAD request results in an error, a message will be > returned > > to the client. Even though this behavior breaks Commons HTTP > > Client (HEAD requests are handled slightly differently and > causes > > the client to hang if a payload is returned), I think it's > > beneficial to tell the user what went wrong. It's worth to > mention > > that Jetty/Netty HTTP clients work correctly. > > * RestServer doesn't implement Lifecycle now. The protocol server > > doesn't support start() method without any arguments. You always > > need to specify configuration + Embedded Cache Manager. > > > > Even though it's a long list, I think all those changes were > worth it. > > Please let me know if you don't agree. > > Couple of other questions: > > * do we accept GET with Range header on keys? What about > delta-updating > entries with Content-Range on PUTs? > > > 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... > > * For PUTs/POSTs, do we return 200/201/204 according to the spec? > (modified/created/modified) > > > No, I decided to leave it as 200 for compatibility reasons. But I > agree, we could change this as well.
Compatibility reasons? You mean compatibility with clients not adhering to spec? (clients should accept any 2xy as success by definition). > > * Do we have any way to execute a replace (or the other prev-value > returning ops) through REST using single request? For example let > DELETE > return the prev entity (it should return 200 & entity or 204 and no > response) > > > 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. I have misformulated the question. I meant to ask if there is a way to return the previous value when you've replaced it? > > [1] > https://github.com/infinispan/infinispan/pull/5094/files#diff-58f67698080cc0242320614c921559a8R301 Looking into the code, without considering performance at all, I think that you've become too ecstatic about Optionals. These should be used as return types for methods, not a) parameters to methods nor b) fields. This is a misuse of the API, according to the authors of Optionals in JDK. Most of the time, you're not using optionals to have fluent chain of method invocations, so -100 to that. > * Do we handle OPTIONS in any way? > > > No. Do we need it? I haven't seen any real implementation that uses > that for discovering REST operations. > > > Radim > > > > > Thanks, > > Sebastian > > > > -- > > > > SEBASTIANŁASKAWIEC > > > > INFINISPAN DEVELOPER > > > > Red HatEMEA <https://www.redhat.com/> > > > > <https://red.ht/sig> > > > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rva...@redhat.com <mailto:rva...@redhat.com>> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > > SEBASTIANŁASKAWIEC > > INFINISPAN DEVELOPER > > Red HatEMEA <https://www.redhat.com/> > > <https://red.ht/sig> > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev