[infinispan-dev] REST Refactoring - breaking changes

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] REST Refactoring - breaking changes

Sebastian Laskawiec
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.
  • 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.
  • 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.

Thanks,
Sebastian

--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] REST Refactoring - breaking changes

Galder Zamarreño
All look good to me :)

Thanks Sebastian!
--
Galder Zamarreño
Infinispan, Red Hat

> On 16 May 2017, at 11:05, Sebastian Laskawiec <[hidden email]> 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.
> • 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.
> • 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.
>
> Thanks,
> Sebastian
>
> --
> SEBASTIAN ŁASKAWIEC
> INFINISPAN DEVELOPER
> Red Hat EMEA
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] REST Refactoring - breaking changes

Radim Vansa
In reply to this post by Sebastian Laskawiec
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] REST Refactoring - breaking changes

Sebastian Laskawiec


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

 
* 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] REST Refactoring - breaking changes

Radim Vansa
On 05/24/2017 10:44 AM, Sebastian Laskawiec wrote:

>
>
> On Tue, May 23, 2017 at 5:06 PM Radim Vansa <[hidden email]
> <mailto:[hidden email]>> 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
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] REST Refactoring - breaking changes

Sebastian Laskawiec


On Thu, May 25, 2017 at 7:42 AM Radim Vansa <[hidden email]> wrote:
On 05/24/2017 10:44 AM, Sebastian Laskawiec wrote:
>
>
> On Tue, May 23, 2017 at 5:06 PM Radim Vansa <[hidden email]
> <mailto:[hidden email]>> 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?

Unfortunately no. And there wasn't in previous REST implementation as far as I know.
 


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

Answered in "To Optional or not to Optional thread".
 

>     * 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
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...