Quantcast

[infinispan-dev] REST Refactoring - breaking changes

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] REST Refactoring - breaking changes

Sebastian Laskawiec
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


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Galder Zamarreño
All look good to me :)

Thanks Sebastian!
--
Galder Zamarreño
Infinispan, Red Hat

> On 16 May 2017, at 11:05, Sebastian Laskawiec <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...