[infinispan-dev] REST Refactoring - breaking changes

[Sebastian Laskawiec]

On Tue, May 23, 2017 at 5:06 PM Radim Vansa <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.


> * 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.

[1]
https://github.com/infinispan/infinispan/pull/5094/files#diff-58f67698080cc0242320614c921559a8R301


> * 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
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER

Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170524/7dc534aa/attachment.html