On 16 May 2017, at 11:05, Sebastian Laskawiec <slaskawi(a)redhat.com&gt; 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. • 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. • 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. Thanks, Sebastian -- SEBASTIAN ŁASKAWIEC INFINISPAN DEVELOPER Red Hat EMEA _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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?

> * 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?

* For PUTs/POSTs, do we return 200/201/204 according to the spec? (modified/created/modified)

* 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)

* Do we handle OPTIONS in any way?

Radim > > Thanks, > Sebastian > > -- > > SEBASTIANŁASKAWIEC > > INFINISPAN DEVELOPER > > Red HatEMEA <https://www.redhat.com/> > > <https://red.ht/sig> > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 05/24/2017 10:44 AM, Sebastian Laskawiec wrote: > > > On Tue, May 23, 2017 at 5:06 PM Radim Vansa <rvansa(a)redhat.com > <mailto:rvansa@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-58f67698080... 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(a)lists.jboss.org > <mailto:infinispan-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org <mailto: infinispan-dev(a)lists.jboss.org&gt; > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev