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>
JBoss Performance Team