[infinispan-dev] REST Refactoring - breaking changes

[Radim Vansa]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team