Re: [infinispan-dev] REST Refactoring - breaking changes

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