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@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
