5:14 p.m.
On 05/24/2017 10:44 AM, Sebastian Laskawiec wrote:
On Tue, May 23, 2017 at 5:06 PM Radim Vansa <rvansa(a)redhat.com
<mailto:rvansa@redhat.com>> wrote:
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?
Exactly. You may try it using our Docker image and invoking something
like this: curl -v -u user:changeme http://172.17.0.6:8080/rest
> * 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?
No and AFAK there are no plans to do it (but perhaps Tristan could
shed some more light onto this). We could use HTTP PATCH for delta
updates...
* For PUTs/POSTs, do we return 200/201/204 according to the spec?
(modified/created/modified)
No, I decided to leave it as 200 for compatibility reasons. But I
agree, we could change this as well.
Compatibility reasons? You mean compatibility with clients not adhering
to spec? (clients should accept any 2xy as success by definition).
* 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)
Yes, PUT replaces previous value [1] if such exists (whereas POST
would return a conflict). If for some reason you can not replace
current value, you will get a preconditions failed error.
I have misformulated the question. I meant to ask if there is a way to
return the previous value when you've replaced it?
Looking into the code, without considering performance at all, I think
that you've become too ecstatic about Optionals. These should be used as
return types for methods, not a) parameters to methods nor b) fields.
This is a misuse of the API, according to the authors of Optionals in
JDK. Most of the time, you're not using optionals to have fluent chain
of method invocations, so -100 to that.
* Do we handle OPTIONS in any way?
No. Do we need it? I haven't seen any real implementation that uses
that for discovering REST operations.
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
<mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
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