Microprofile OpenAPI

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Microprofile OpenAPI

Ivan Junckes Filho
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and fully relies on JAXRS for that so if you have a body writer which matches OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like "text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any environment and does not enforce yaml as well cause it is not part of the core of microprofile (and hopefully will never be) so no reason to import a lib (which can be heavy and potentially with vulnerabilities + work for the users to maintain it) for that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho <[hidden email]> a écrit :
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Ivan Junckes Filho
Hey Romain, take a look on:


It is clear for me there, that the default should be yaml.

On Thu, Nov 29, 2018 at 2:58 PM Romain Manni-Bucau <[hidden email]> wrote:
Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and fully relies on JAXRS for that so if you have a body writer which matches OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like "text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any environment and does not enforce yaml as well cause it is not part of the core of microprofile (and hopefully will never be) so no reason to import a lib (which can be heavy and potentially with vulnerabilities + work for the users to maintain it) for that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho <[hidden email]> a écrit :
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Bruno Baptista
In reply to this post by Romain Manni-Bucau

Hi Romain,

Independent of the implementation details, if we have to specify the accept header with "text/yaml", the response in not yaml by default like the spec says... right?

Ivan, Is there a test in the TCK to make sure the default is yaml?

Cheers




On 29/11/18 16:58, Romain Manni-Bucau wrote:
Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and fully relies on JAXRS for that so if you have a body writer which matches OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like "text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any environment and does not enforce yaml as well cause it is not part of the core of microprofile (and hopefully will never be) so no reason to import a lib (which can be heavy and potentially with vulnerabilities + work for the users to maintain it) for that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho <[hidden email]> a écrit :
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
Well the point is not much what the spec says, the implementation supports all that since it lets the writer setup be done in the integrations if needed.

See it from the point of view of the lib:

1. 99% of the case will be json and json is well set up for microprofile
2. yaml libs are different for most servers so no reason to impose one or even make it conflicting

=> the integration needs to customize the writers if needed

In the lib the most we could do is to not default to json if the mediatype is null adding a config to default to yaml but often yaml writer don't answer to text/yaml so not sure it would be good for users. I will open a MP ticket about that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 18:07, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Independent of the implementation details, if we have to specify the accept header with "text/yaml", the response in not yaml by default like the spec says... right?

Ivan, Is there a test in the TCK to make sure the default is yaml?

Cheers




On 29/11/18 16:58, Romain Manni-Bucau wrote:
Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and fully relies on JAXRS for that so if you have a body writer which matches OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like "text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any environment and does not enforce yaml as well cause it is not part of the core of microprofile (and hopefully will never be) so no reason to import a lib (which can be heavy and potentially with vulnerabilities + work for the users to maintain it) for that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho <[hidden email]> a écrit :
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Bruno Baptista

+1 on getting an MP clarification on this.

On 29/11/18 17:10, Romain Manni-Bucau wrote:
Well the point is not much what the spec says, the implementation supports all that since it lets the writer setup be done in the integrations if needed.

See it from the point of view of the lib:

1. 99% of the case will be json and json is well set up for microprofile
2. yaml libs are different for most servers so no reason to impose one or even make it conflicting

=> the integration needs to customize the writers if needed

In the lib the most we could do is to not default to json if the mediatype is null adding a config to default to yaml but often yaml writer don't answer to text/yaml so not sure it would be good for users. I will open a MP ticket about that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 18:07, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Independent of the implementation details, if we have to specify the accept header with "text/yaml", the response in not yaml by default like the spec says... right?

Ivan, Is there a test in the TCK to make sure the default is yaml?

Cheers




On 29/11/18 16:58, Romain Manni-Bucau wrote:
Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and fully relies on JAXRS for that so if you have a body writer which matches OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like "text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any environment and does not enforce yaml as well cause it is not part of the core of microprofile (and hopefully will never be) so no reason to import a lib (which can be heavy and potentially with vulnerabilities + work for the users to maintain it) for that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho <[hidden email]> a écrit :
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Ivan Junckes Filho
Please share the ticket here Romain, so everybody can follow.

On Thu, Nov 29, 2018 at 3:16 PM Bruno Baptista <[hidden email]> wrote:

+1 on getting an MP clarification on this.

On 29/11/18 17:10, Romain Manni-Bucau wrote:
Well the point is not much what the spec says, the implementation supports all that since it lets the writer setup be done in the integrations if needed.

See it from the point of view of the lib:

1. 99% of the case will be json and json is well set up for microprofile
2. yaml libs are different for most servers so no reason to impose one or even make it conflicting

=> the integration needs to customize the writers if needed

In the lib the most we could do is to not default to json if the mediatype is null adding a config to default to yaml but often yaml writer don't answer to text/yaml so not sure it would be good for users. I will open a MP ticket about that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 18:07, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Independent of the implementation details, if we have to specify the accept header with "text/yaml", the response in not yaml by default like the spec says... right?

Ivan, Is there a test in the TCK to make sure the default is yaml?

Cheers




On 29/11/18 16:58, Romain Manni-Bucau wrote:
Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and fully relies on JAXRS for that so if you have a body writer which matches OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like "text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any environment and does not enforce yaml as well cause it is not part of the core of microprofile (and hopefully will never be) so no reason to import a lib (which can be heavy and potentially with vulnerabilities + work for the users to maintain it) for that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho <[hidden email]> a écrit :
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
https://github.com/eclipse/microprofile-open-api/issues/302

Side note - if i got the real question: tomee still needs to setup writers correctly in mp common module if im not mistaken (to at least handle "q" correctly if accepts has both json and yaml without weights)

Le jeu. 29 nov. 2018 18:22, Ivan Junckes Filho <[hidden email]> a écrit :
Please share the ticket here Romain, so everybody can follow.

On Thu, Nov 29, 2018 at 3:16 PM Bruno Baptista <[hidden email]> wrote:

+1 on getting an MP clarification on this.

On 29/11/18 17:10, Romain Manni-Bucau wrote:
Well the point is not much what the spec says, the implementation supports all that since it lets the writer setup be done in the integrations if needed.

See it from the point of view of the lib:

1. 99% of the case will be json and json is well set up for microprofile
2. yaml libs are different for most servers so no reason to impose one or even make it conflicting

=> the integration needs to customize the writers if needed

In the lib the most we could do is to not default to json if the mediatype is null adding a config to default to yaml but often yaml writer don't answer to text/yaml so not sure it would be good for users. I will open a MP ticket about that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 18:07, Bruno Baptista <[hidden email]> a écrit :

Hi Romain,

Independent of the implementation details, if we have to specify the accept header with "text/yaml", the response in not yaml by default like the spec says... right?

Ivan, Is there a test in the TCK to make sure the default is yaml?

Cheers




On 29/11/18 16:58, Romain Manni-Bucau wrote:
Hello Ivan,

this is actually not exactly the case, the impl is writer agnostic and fully relies on JAXRS for that so if you have a body writer which matches OpenAPI and returns yaml by default or
which prefer yaml over json then you will have the behavior you describe.

To get yaml you can send the Accept header valued with yaml media type like "text/yaml" for some implementations.

Side note: the impl does not impose any body writer to be integrable in any environment and does not enforce yaml as well cause it is not part of the core of microprofile (and hopefully will never be) so no reason to import a lib (which can be heavy and potentially with vulnerabilities + work for the users to maintain it) for that.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le jeu. 29 nov. 2018 à 17:50, Ivan Junckes Filho <[hidden email]> a écrit :
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

jgallimore
In reply to this post by Ivan Junckes Filho
If the spec requires that, then I'd expect to get a YAML response if making a request without an `Accept` header on the request.

I haven't looked through the microprofile-openapi TCK, but I'd expect that to be tested, and I'd suggest contributing a test there if there isn't one.

If you wanted to explicitly request a YAML response, I'd expect one of these to work:

Accept: application/x-yaml
Accept: text/yaml

I'd expect a Content-Type header on the response to identify the mime type of the response, whatever is being returned.

Jon

On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <[hidden email]> wrote:
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
Response is fine (thanks jaxrs), request is up to jaxrs runtime so depends where you deploy it (i dont think implementing a custom writer for that is right for users, it has too much pitfalls once integrated to anything else than this very specific spec).

Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <[hidden email]> a écrit :
If the spec requires that, then I'd expect to get a YAML response if making a request without an `Accept` header on the request.

I haven't looked through the microprofile-openapi TCK, but I'd expect that to be tested, and I'd suggest contributing a test there if there isn't one.

If you wanted to explicitly request a YAML response, I'd expect one of these to work:

Accept: application/x-yaml
Accept: text/yaml

I'd expect a Content-Type header on the response to identify the mime type of the response, whatever is being returned.

Jon

On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <[hidden email]> wrote:
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

John D. Ament
The question posed to the MP team does not really match the question posted here, and seems to be a tangental ask.  

The problem is this line of code [1], and nothing to do with TomEE's behavior; it defaults to JSON even though the spec states it should be YAML.  Perhaps a clean solution would be to make this a config setting?  But seems like there's a missing TCK test as well.  I'd also question when a browser goes here, what does it send in the Accepts header.  My guess is most modern browsers send text/html which also wouldn't line up.

John


On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <[hidden email]> wrote:
Response is fine (thanks jaxrs), request is up to jaxrs runtime so depends where you deploy it (i dont think implementing a custom writer for that is right for users, it has too much pitfalls once integrated to anything else than this very specific spec).

Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <[hidden email]> a écrit :
If the spec requires that, then I'd expect to get a YAML response if making a request without an `Accept` header on the request.

I haven't looked through the microprofile-openapi TCK, but I'd expect that to be tested, and I'd suggest contributing a test there if there isn't one.

If you wanted to explicitly request a YAML response, I'd expect one of these to work:

Accept: application/x-yaml
Accept: text/yaml

I'd expect a Content-Type header on the response to identify the mime type of the response, whatever is being returned.

Jon

On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <[hidden email]> wrote:
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
Browser and all clients default to */* or octect/stream so the else is never used normally and was here just to put a mimetype from an optional.

Browsers even send a kind of "all you can" value (*/*, html, xml at least).

So yes we can make this value confifurable but this never happens. Ivan's case was even with cxf client which sets a value normally by default so it wouldnt help I think.

Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a écrit :
The question posed to the MP team does not really match the question posted here, and seems to be a tangental ask.  

The problem is this line of code [1], and nothing to do with TomEE's behavior; it defaults to JSON even though the spec states it should be YAML.  Perhaps a clean solution would be to make this a config setting?  But seems like there's a missing TCK test as well.  I'd also question when a browser goes here, what does it send in the Accepts header.  My guess is most modern browsers send text/html which also wouldn't line up.

John


On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <[hidden email]> wrote:
Response is fine (thanks jaxrs), request is up to jaxrs runtime so depends where you deploy it (i dont think implementing a custom writer for that is right for users, it has too much pitfalls once integrated to anything else than this very specific spec).

Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <[hidden email]> a écrit :
If the spec requires that, then I'd expect to get a YAML response if making a request without an `Accept` header on the request.

I haven't looked through the microprofile-openapi TCK, but I'd expect that to be tested, and I'd suggest contributing a test there if there isn't one.

If you wanted to explicitly request a YAML response, I'd expect one of these to work:

Accept: application/x-yaml
Accept: text/yaml

I'd expect a Content-Type header on the response to identify the mime type of the response, whatever is being returned.

Jon

On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <[hidden email]> wrote:
Hey guys, I think I found a bug in OpenAPI implementation.

The spec says:
"The default format of the /openapi endpoint is YAML."

But when I try to access /openapi it returns JSON by default.

This is not correct.

Also how can I access yaml if it is not default?
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Ivan Junckes Filho
I think regardless of what the MicroProfile team decides, we need to make it work as the specification says. Then iterate from there. 

In my opinion this is a big problem that makes us strongly incompatible with the standard.

On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <[hidden email]> wrote:
Browser and all clients default to */* or octect/stream so the else is
never used normally and was here just to put a mimetype from an optional.

Browsers even send a kind of "all you can" value (*/*, html, xml at least).

So yes we can make this value confifurable but this never happens. Ivan's
case was even with cxf client which sets a value normally by default so it
wouldnt help I think.

Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a écrit :

> The question posed to the MP team does not really match the question
> posted here, and seems to be a tangental ask.
>
> The problem is this line of code [1], and nothing to do with TomEE's
> behavior; it defaults to JSON even though the spec states it should be
> YAML.  Perhaps a clean solution would be to make this a config setting?
> But seems like there's a missing TCK test as well.  I'd also question when
> a browser goes here, what does it send in the Accepts header.  My guess is
> most modern browsers send text/html which also wouldn't line up.
>
> John
>
> [1]:
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>
> On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <[hidden email]>
> wrote:
>
>> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>> depends where you deploy it (i dont think implementing a custom writer for
>> that is right for users, it has too much pitfalls once integrated to
>> anything else than this very specific spec).
>>
>> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>> [hidden email]> a écrit :
>>
>>> If the spec requires that, then I'd expect to get a YAML response if
>>> making a request without an `Accept` header on the request.
>>>
>>> I haven't looked through the microprofile-openapi TCK, but I'd expect
>>> that to be tested, and I'd suggest contributing a test there if there isn't
>>> one.
>>>
>>> If you wanted to explicitly request a YAML response, I'd expect one of
>>> these to work:
>>>
>>> Accept: application/x-yaml
>>> Accept: text/yaml
>>>
>>> I'd expect a Content-Type header on the response to identify the mime
>>> type of the response, whatever is being returned.
>>>
>>> Jon
>>>
>>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>>> [hidden email]> wrote:
>>>
>>>> Hey guys, I think I found a bug in OpenAPI implementation.
>>>>
>>>> The spec says:
>>>> "The default format of the /openapi endpoint is YAML."
>>>>
>>>> But when I try to access /openapi it returns JSON by default.
>>>>
>>>> This is not correct.
>>>>
>>>> Also how can I access yaml if it is not default?
>>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
I'll add */* for yaml endpoint to complement text/plain, this will solve the ambiguity

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 12:44, Ivan Junckes Filho <[hidden email]> a écrit :
I think regardless of what the MicroProfile team decides, we need to make it work as the specification says. Then iterate from there. 

In my opinion this is a big problem that makes us strongly incompatible with the standard.

On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <[hidden email]> wrote:
Browser and all clients default to */* or octect/stream so the else is
never used normally and was here just to put a mimetype from an optional.

Browsers even send a kind of "all you can" value (*/*, html, xml at least).

So yes we can make this value confifurable but this never happens. Ivan's
case was even with cxf client which sets a value normally by default so it
wouldnt help I think.

Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a écrit :

> The question posed to the MP team does not really match the question
> posted here, and seems to be a tangental ask.
>
> The problem is this line of code [1], and nothing to do with TomEE's
> behavior; it defaults to JSON even though the spec states it should be
> YAML.  Perhaps a clean solution would be to make this a config setting?
> But seems like there's a missing TCK test as well.  I'd also question when
> a browser goes here, what does it send in the Accepts header.  My guess is
> most modern browsers send text/html which also wouldn't line up.
>
> John
>
> [1]:
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
>
> On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <[hidden email]>
> wrote:
>
>> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
>> depends where you deploy it (i dont think implementing a custom writer for
>> that is right for users, it has too much pitfalls once integrated to
>> anything else than this very specific spec).
>>
>> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
>> [hidden email]> a écrit :
>>
>>> If the spec requires that, then I'd expect to get a YAML response if
>>> making a request without an `Accept` header on the request.
>>>
>>> I haven't looked through the microprofile-openapi TCK, but I'd expect
>>> that to be tested, and I'd suggest contributing a test there if there isn't
>>> one.
>>>
>>> If you wanted to explicitly request a YAML response, I'd expect one of
>>> these to work:
>>>
>>> Accept: application/x-yaml
>>> Accept: text/yaml
>>>
>>> I'd expect a Content-Type header on the response to identify the mime
>>> type of the response, whatever is being returned.
>>>
>>> Jon
>>>
>>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
>>> [hidden email]> wrote:
>>>
>>>> Hey guys, I think I found a bug in OpenAPI implementation.
>>>>
>>>> The spec says:
>>>> "The default format of the /openapi endpoint is YAML."
>>>>
>>>> But when I try to access /openapi it returns JSON by default.
>>>>
>>>> This is not correct.
>>>>
>>>> Also how can I access yaml if it is not default?
>>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Ivan Junckes Filho
In reply to this post by Ivan Junckes Filho
[hidden email] not sure I understood you. Are you saying you will work to make it compatible with the spec? Have yaml as default?

On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <[hidden email]> wrote:
>
> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.


+1

El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<[hidden email]>)
escribió:

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > Browser and all clients default to */* or octect/stream so the else is
> > never used normally and was here just to put a mimetype from an optional.
> >
> > Browsers even send a kind of "all you can" value (*/*, html, xml at
> least).
> >
> > So yes we can make this value confifurable but this never happens. Ivan's
> > case was even with cxf client which sets a value normally by default so
> it
> > wouldnt help I think.
> >
> > Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a
> écrit
> > :
> >
> > > The question posed to the MP team does not really match the question
> > > posted here, and seems to be a tangental ask.
> > >
> > > The problem is this line of code [1], and nothing to do with TomEE's
> > > behavior; it defaults to JSON even though the spec states it should be
> > > YAML.  Perhaps a clean solution would be to make this a config setting?
> > > But seems like there's a missing TCK test as well.  I'd also question
> > when
> > > a browser goes here, what does it send in the Accepts header.  My guess
> > is
> > > most modern browsers send text/html which also wouldn't line up.
> > >
> > > John
> > >
> > > [1]:
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >
> > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > [hidden email]>
> > > wrote:
> > >
> > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> > >> depends where you deploy it (i dont think implementing a custom writer
> > for
> > >> that is right for users, it has too much pitfalls once integrated to
> > >> anything else than this very specific spec).
> > >>
> > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >> [hidden email]> a écrit :
> > >>
> > >>> If the spec requires that, then I'd expect to get a YAML response if
> > >>> making a request without an `Accept` header on the request.
> > >>>
> > >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
> > >>> that to be tested, and I'd suggest contributing a test there if there
> > isn't
> > >>> one.
> > >>>
> > >>> If you wanted to explicitly request a YAML response, I'd expect one
> of
> > >>> these to work:
> > >>>
> > >>> Accept: application/x-yaml
> > >>> Accept: text/yaml
> > >>>
> > >>> I'd expect a Content-Type header on the response to identify the mime
> > >>> type of the response, whatever is being returned.
> > >>>
> > >>> Jon
> > >>>
> > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>
> > >>>> The spec says:
> > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>
> > >>>> But when I try to access /openapi it returns JSON by default.
> > >>>>
> > >>>> This is not correct.
> > >>>>
> > >>>> Also how can I access yaml if it is not default?
> > >>>>
> > >>>
> >
>


--
Atentamente:
César Hernández Mendoza.
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
If jackson yaml is present it will add a (jackson) writer for yaml, if not it stays on json.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <[hidden email]> a écrit :
[hidden email] not sure I understood you. Are you saying you will work to make it compatible with the spec? Have yaml as default?

On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <[hidden email]> wrote:
>
> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.


+1

El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<[hidden email]>)
escribió:

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > Browser and all clients default to */* or octect/stream so the else is
> > never used normally and was here just to put a mimetype from an optional.
> >
> > Browsers even send a kind of "all you can" value (*/*, html, xml at
> least).
> >
> > So yes we can make this value confifurable but this never happens. Ivan's
> > case was even with cxf client which sets a value normally by default so
> it
> > wouldnt help I think.
> >
> > Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a
> écrit
> > :
> >
> > > The question posed to the MP team does not really match the question
> > > posted here, and seems to be a tangental ask.
> > >
> > > The problem is this line of code [1], and nothing to do with TomEE's
> > > behavior; it defaults to JSON even though the spec states it should be
> > > YAML.  Perhaps a clean solution would be to make this a config setting?
> > > But seems like there's a missing TCK test as well.  I'd also question
> > when
> > > a browser goes here, what does it send in the Accepts header.  My guess
> > is
> > > most modern browsers send text/html which also wouldn't line up.
> > >
> > > John
> > >
> > > [1]:
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >
> > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > [hidden email]>
> > > wrote:
> > >
> > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> > >> depends where you deploy it (i dont think implementing a custom writer
> > for
> > >> that is right for users, it has too much pitfalls once integrated to
> > >> anything else than this very specific spec).
> > >>
> > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >> [hidden email]> a écrit :
> > >>
> > >>> If the spec requires that, then I'd expect to get a YAML response if
> > >>> making a request without an `Accept` header on the request.
> > >>>
> > >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
> > >>> that to be tested, and I'd suggest contributing a test there if there
> > isn't
> > >>> one.
> > >>>
> > >>> If you wanted to explicitly request a YAML response, I'd expect one
> of
> > >>> these to work:
> > >>>
> > >>> Accept: application/x-yaml
> > >>> Accept: text/yaml
> > >>>
> > >>> I'd expect a Content-Type header on the response to identify the mime
> > >>> type of the response, whatever is being returned.
> > >>>
> > >>> Jon
> > >>>
> > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>
> > >>>> The spec says:
> > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>
> > >>>> But when I try to access /openapi it returns JSON by default.
> > >>>>
> > >>>> This is not correct.
> > >>>>
> > >>>> Also how can I access yaml if it is not default?
> > >>>>
> > >>>
> >
>


--
Atentamente:
César Hernández Mendoza.
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Ivan Junckes Filho
This is against the spec as well, yaml is required and must always be default. Do we really want to let our implementation not compatible with that?

On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau <[hidden email]> wrote:
If jackson yaml is present it will add a (jackson) writer for yaml, if not it stays on json.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <[hidden email]> a écrit :
[hidden email] not sure I understood you. Are you saying you will work to make it compatible with the spec? Have yaml as default?

On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <[hidden email]> wrote:
>
> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.


+1

El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<[hidden email]>)
escribió:

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > Browser and all clients default to */* or octect/stream so the else is
> > never used normally and was here just to put a mimetype from an optional.
> >
> > Browsers even send a kind of "all you can" value (*/*, html, xml at
> least).
> >
> > So yes we can make this value confifurable but this never happens. Ivan's
> > case was even with cxf client which sets a value normally by default so
> it
> > wouldnt help I think.
> >
> > Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a
> écrit
> > :
> >
> > > The question posed to the MP team does not really match the question
> > > posted here, and seems to be a tangental ask.
> > >
> > > The problem is this line of code [1], and nothing to do with TomEE's
> > > behavior; it defaults to JSON even though the spec states it should be
> > > YAML.  Perhaps a clean solution would be to make this a config setting?
> > > But seems like there's a missing TCK test as well.  I'd also question
> > when
> > > a browser goes here, what does it send in the Accepts header.  My guess
> > is
> > > most modern browsers send text/html which also wouldn't line up.
> > >
> > > John
> > >
> > > [1]:
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >
> > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > [hidden email]>
> > > wrote:
> > >
> > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> > >> depends where you deploy it (i dont think implementing a custom writer
> > for
> > >> that is right for users, it has too much pitfalls once integrated to
> > >> anything else than this very specific spec).
> > >>
> > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >> [hidden email]> a écrit :
> > >>
> > >>> If the spec requires that, then I'd expect to get a YAML response if
> > >>> making a request without an `Accept` header on the request.
> > >>>
> > >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
> > >>> that to be tested, and I'd suggest contributing a test there if there
> > isn't
> > >>> one.
> > >>>
> > >>> If you wanted to explicitly request a YAML response, I'd expect one
> of
> > >>> these to work:
> > >>>
> > >>> Accept: application/x-yaml
> > >>> Accept: text/yaml
> > >>>
> > >>> I'd expect a Content-Type header on the response to identify the mime
> > >>> type of the response, whatever is being returned.
> > >>>
> > >>> Jon
> > >>>
> > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>
> > >>>> The spec says:
> > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>
> > >>>> But when I try to access /openapi it returns JSON by default.
> > >>>>
> > >>>> This is not correct.
> > >>>>
> > >>>> Also how can I access yaml if it is not default?
> > >>>>
> > >>>
> >
>


--
Atentamente:
César Hernández Mendoza.
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
I don't understand why you say so Ivan, it is perfectly compatible.

Also to answer clearly to your question: I prefer to have an impl not compatible with the spec when the spec says something stupid, most of the time we put toggle to be able to be compatible but sometimes there is not even a way to be compatible, this is what has been done in TomEE since years and it works well making users happy rather than spec leads.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho <[hidden email]> a écrit :
This is against the spec as well, yaml is required and must always be default. Do we really want to let our implementation not compatible with that?

On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau <[hidden email]> wrote:
If jackson yaml is present it will add a (jackson) writer for yaml, if not it stays on json.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <[hidden email]> a écrit :
[hidden email] not sure I understood you. Are you saying you will work to make it compatible with the spec? Have yaml as default?

On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <[hidden email]> wrote:
>
> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.


+1

El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<[hidden email]>)
escribió:

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > Browser and all clients default to */* or octect/stream so the else is
> > never used normally and was here just to put a mimetype from an optional.
> >
> > Browsers even send a kind of "all you can" value (*/*, html, xml at
> least).
> >
> > So yes we can make this value confifurable but this never happens. Ivan's
> > case was even with cxf client which sets a value normally by default so
> it
> > wouldnt help I think.
> >
> > Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a
> écrit
> > :
> >
> > > The question posed to the MP team does not really match the question
> > > posted here, and seems to be a tangental ask.
> > >
> > > The problem is this line of code [1], and nothing to do with TomEE's
> > > behavior; it defaults to JSON even though the spec states it should be
> > > YAML.  Perhaps a clean solution would be to make this a config setting?
> > > But seems like there's a missing TCK test as well.  I'd also question
> > when
> > > a browser goes here, what does it send in the Accepts header.  My guess
> > is
> > > most modern browsers send text/html which also wouldn't line up.
> > >
> > > John
> > >
> > > [1]:
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >
> > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > [hidden email]>
> > > wrote:
> > >
> > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> > >> depends where you deploy it (i dont think implementing a custom writer
> > for
> > >> that is right for users, it has too much pitfalls once integrated to
> > >> anything else than this very specific spec).
> > >>
> > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >> [hidden email]> a écrit :
> > >>
> > >>> If the spec requires that, then I'd expect to get a YAML response if
> > >>> making a request without an `Accept` header on the request.
> > >>>
> > >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
> > >>> that to be tested, and I'd suggest contributing a test there if there
> > isn't
> > >>> one.
> > >>>
> > >>> If you wanted to explicitly request a YAML response, I'd expect one
> of
> > >>> these to work:
> > >>>
> > >>> Accept: application/x-yaml
> > >>> Accept: text/yaml
> > >>>
> > >>> I'd expect a Content-Type header on the response to identify the mime
> > >>> type of the response, whatever is being returned.
> > >>>
> > >>> Jon
> > >>>
> > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>
> > >>>> The spec says:
> > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>
> > >>>> But when I try to access /openapi it returns JSON by default.
> > >>>>
> > >>>> This is not correct.
> > >>>>
> > >>>> Also how can I access yaml if it is not default?
> > >>>>
> > >>>
> >
>


--
Atentamente:
César Hernández Mendoza.
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Ivan Junckes Filho
The goal for this is to implement Microprofile Specifications. So what the Microprofile community decides is important and needs to be followed. Of course everyone has a voice there and you clearly spoke up there which is great. You think it is not the best approach, but people there until now think it is. So why not respect what they decide?

It would be compatible if you put yaml by default and choose to make json default with a property. But making json default and adding extra configs to make yaml default is not what the spec defines.

This is the standard:
"The default format of the /openapi endpoint is YAML.

Anything different than this is what you think is the best and not a consensus in the MicroProfile community. "Stupid" is a very personal opinion and doesn't reflect what people think about it there, neither my opinion.

I again, think we should follow what the standard is and change later if the community decides so.

On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <[hidden email]> wrote:
I don't understand why you say so Ivan, it is perfectly compatible.

Also to answer clearly to your question: I prefer to have an impl not compatible with the spec when the spec says something stupid, most of the time we put toggle to be able to be compatible but sometimes there is not even a way to be compatible, this is what has been done in TomEE since years and it works well making users happy rather than spec leads.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho <[hidden email]> a écrit :
This is against the spec as well, yaml is required and must always be default. Do we really want to let our implementation not compatible with that?

On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau <[hidden email]> wrote:
If jackson yaml is present it will add a (jackson) writer for yaml, if not it stays on json.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <[hidden email]> a écrit :
[hidden email] not sure I understood you. Are you saying you will work to make it compatible with the spec? Have yaml as default?

On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <[hidden email]> wrote:
>
> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.


+1

El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<[hidden email]>)
escribió:

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > Browser and all clients default to */* or octect/stream so the else is
> > never used normally and was here just to put a mimetype from an optional.
> >
> > Browsers even send a kind of "all you can" value (*/*, html, xml at
> least).
> >
> > So yes we can make this value confifurable but this never happens. Ivan's
> > case was even with cxf client which sets a value normally by default so
> it
> > wouldnt help I think.
> >
> > Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a
> écrit
> > :
> >
> > > The question posed to the MP team does not really match the question
> > > posted here, and seems to be a tangental ask.
> > >
> > > The problem is this line of code [1], and nothing to do with TomEE's
> > > behavior; it defaults to JSON even though the spec states it should be
> > > YAML.  Perhaps a clean solution would be to make this a config setting?
> > > But seems like there's a missing TCK test as well.  I'd also question
> > when
> > > a browser goes here, what does it send in the Accepts header.  My guess
> > is
> > > most modern browsers send text/html which also wouldn't line up.
> > >
> > > John
> > >
> > > [1]:
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >
> > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > [hidden email]>
> > > wrote:
> > >
> > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> > >> depends where you deploy it (i dont think implementing a custom writer
> > for
> > >> that is right for users, it has too much pitfalls once integrated to
> > >> anything else than this very specific spec).
> > >>
> > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >> [hidden email]> a écrit :
> > >>
> > >>> If the spec requires that, then I'd expect to get a YAML response if
> > >>> making a request without an `Accept` header on the request.
> > >>>
> > >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
> > >>> that to be tested, and I'd suggest contributing a test there if there
> > isn't
> > >>> one.
> > >>>
> > >>> If you wanted to explicitly request a YAML response, I'd expect one
> of
> > >>> these to work:
> > >>>
> > >>> Accept: application/x-yaml
> > >>> Accept: text/yaml
> > >>>
> > >>> I'd expect a Content-Type header on the response to identify the mime
> > >>> type of the response, whatever is being returned.
> > >>>
> > >>> Jon
> > >>>
> > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>
> > >>>> The spec says:
> > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>
> > >>>> But when I try to access /openapi it returns JSON by default.
> > >>>>
> > >>>> This is not correct.
> > >>>>
> > >>>> Also how can I access yaml if it is not default?
> > >>>>
> > >>>
> >
>


--
Atentamente:
César Hernández Mendoza.
Reply | Threaded
Open this post in threaded view
|

Re: Microprofile OpenAPI

Romain Manni-Bucau
Well, I don't aim to have an argument here but please also consider that I can ask as well why you (not sure who is "people" cause I see mainly 1 voice here which vendor voice) woudln't respect user feedback which is regularly pro json in several companies - I know the spec picked yaml for "other$" reasons.

Also note that, as I mentionned, the implementation is now compliant to the spec, so not really sure the follow up to give to that topic.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 17:25, Ivan Junckes Filho <[hidden email]> a écrit :
The goal for this is to implement Microprofile Specifications. So what the Microprofile community decides is important and needs to be followed. Of course everyone has a voice there and you clearly spoke up there which is great. You think it is not the best approach, but people there until now think it is. So why not respect what they decide?

It would be compatible if you put yaml by default and choose to make json default with a property. But making json default and adding extra configs to make yaml default is not what the spec defines.

This is the standard:
"The default format of the /openapi endpoint is YAML.

Anything different than this is what you think is the best and not a consensus in the MicroProfile community. "Stupid" is a very personal opinion and doesn't reflect what people think about it there, neither my opinion.

I again, think we should follow what the standard is and change later if the community decides so.

On Fri, Nov 30, 2018 at 2:14 PM Romain Manni-Bucau <[hidden email]> wrote:
I don't understand why you say so Ivan, it is perfectly compatible.

Also to answer clearly to your question: I prefer to have an impl not compatible with the spec when the spec says something stupid, most of the time we put toggle to be able to be compatible but sometimes there is not even a way to be compatible, this is what has been done in TomEE since years and it works well making users happy rather than spec leads.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 17:11, Ivan Junckes Filho <[hidden email]> a écrit :
This is against the spec as well, yaml is required and must always be default. Do we really want to let our implementation not compatible with that?

On Fri, Nov 30, 2018 at 2:03 PM Romain Manni-Bucau <[hidden email]> wrote:
If jackson yaml is present it will add a (jackson) writer for yaml, if not it stays on json.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le ven. 30 nov. 2018 à 16:51, Ivan Junckes Filho <[hidden email]> a écrit :
[hidden email] not sure I understood you. Are you saying you will work to make it compatible with the spec? Have yaml as default?

On Fri, Nov 30, 2018 at 1:30 PM César Hernández Mendoza <[hidden email]> wrote:
>
> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.


+1

El vie., 30 nov. 2018 a las 5:44, Ivan Junckes Filho (<[hidden email]>)
escribió:

> I think regardless of what the MicroProfile team decides, we need to make
> it work as the specification says. Then iterate from there.
>
> In my opinion this is a big problem that makes us strongly incompatible
> with the standard.
>
> On Fri, Nov 30, 2018 at 3:36 AM Romain Manni-Bucau <[hidden email]>
> wrote:
>
> > Browser and all clients default to */* or octect/stream so the else is
> > never used normally and was here just to put a mimetype from an optional.
> >
> > Browsers even send a kind of "all you can" value (*/*, html, xml at
> least).
> >
> > So yes we can make this value confifurable but this never happens. Ivan's
> > case was even with cxf client which sets a value normally by default so
> it
> > wouldnt help I think.
> >
> > Le ven. 30 nov. 2018 06:21, John D. Ament <[hidden email]> a
> écrit
> > :
> >
> > > The question posed to the MP team does not really match the question
> > > posted here, and seems to be a tangental ask.
> > >
> > > The problem is this line of code [1], and nothing to do with TomEE's
> > > behavior; it defaults to JSON even though the spec states it should be
> > > YAML.  Perhaps a clean solution would be to make this a config setting?
> > > But seems like there's a missing TCK test as well.  I'd also question
> > when
> > > a browser goes here, what does it send in the Accepts header.  My guess
> > is
> > > most modern browsers send text/html which also wouldn't line up.
> > >
> > > John
> > >
> > > [1]:
> > >
> >
> https://github.com/apache/geronimo-openapi/blob/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/jaxrs/OpenAPIFilter.java#L57
> > >
> > > On Thu, Nov 29, 2018 at 3:58 PM Romain Manni-Bucau <
> > [hidden email]>
> > > wrote:
> > >
> > >> Response is fine (thanks jaxrs), request is up to jaxrs runtime so
> > >> depends where you deploy it (i dont think implementing a custom writer
> > for
> > >> that is right for users, it has too much pitfalls once integrated to
> > >> anything else than this very specific spec).
> > >>
> > >> Le jeu. 29 nov. 2018 21:39, Jonathan Gallimore <
> > >> [hidden email]> a écrit :
> > >>
> > >>> If the spec requires that, then I'd expect to get a YAML response if
> > >>> making a request without an `Accept` header on the request.
> > >>>
> > >>> I haven't looked through the microprofile-openapi TCK, but I'd expect
> > >>> that to be tested, and I'd suggest contributing a test there if there
> > isn't
> > >>> one.
> > >>>
> > >>> If you wanted to explicitly request a YAML response, I'd expect one
> of
> > >>> these to work:
> > >>>
> > >>> Accept: application/x-yaml
> > >>> Accept: text/yaml
> > >>>
> > >>> I'd expect a Content-Type header on the response to identify the mime
> > >>> type of the response, whatever is being returned.
> > >>>
> > >>> Jon
> > >>>
> > >>> On Thu, Nov 29, 2018 at 4:50 PM Ivan Junckes Filho <
> > >>> [hidden email]> wrote:
> > >>>
> > >>>> Hey guys, I think I found a bug in OpenAPI implementation.
> > >>>>
> > >>>> The spec says:
> > >>>> "The default format of the /openapi endpoint is YAML."
> > >>>>
> > >>>> But when I try to access /openapi it returns JSON by default.
> > >>>>
> > >>>> This is not correct.
> > >>>>
> > >>>> Also how can I access yaml if it is not default?
> > >>>>
> > >>>
> >
>


--
Atentamente:
César Hernández Mendoza.
12