[infinispan-dev] REST Refactoring - breaking changes
Radim Vansa
rvansa at redhat.com
Wed May 24 18:14:34 EDT 2017
On 05/24/2017 10:44 AM, Sebastian Laskawiec wrote:
>
>
> On Tue, May 23, 2017 at 5:06 PM Radim Vansa <rvansa at redhat.com
> <mailto:rvansa at 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?
>
> [1]
> https://github.com/infinispan/infinispan/pull/5094/files#diff-58f67698080cc0242320614c921559a8R301
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 at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org <mailto:infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team
More information about the infinispan-dev
mailing list