Re: [httpapi] Introduction

[Christoph Kappestein <[e-mail]>]

Hi all, thanks for the information and pointers.

@Julian just to get a better understanding, if we say that RFCs are finished
documents, does this mean that also those draft RFCs i.e. listed here
https://datatracker.ietf.org/wg/httpapi/documents/ are finished? I totally
understand that RFCs like 3986 are finished and will not change easily or only
in case there is an actual error. But I assumed that we can evolve and iterate
those "draft" RFCs easier until they become a "real" RFC. But this is only my
understanding from an outsider perspective so please let me know whether this
makes sense.

@Rich @Erik thanks for the pointer to JTD, this project looks indeed
interesting.
I had also some contact with the author before and I think both projects have
similar goals but there is also a feature gap. Since JTD is already an RFC it is
probably difficult to change, but if there is a way to evolve this spec I
would be really interested in this. This could then become also an interesting
alternative schema specification for the OpenAPI spec.

@Erik regarding the "Deprecation" header, sure I will let you know if we have
implemented this. I was not aware of the "Content-Warning" RFC, we use the old
"Warning" header with an 199 code only to return the status of an endpoint, we
have currently the status: Experimental, Production, Deprecated,
Closed. The status closed maps probably to the "Sunset" date at the
deprecation header RFC, in this case our gateway simply returns always an 410
status code with an info message. So we use the warning header only for this
information but I will also take a look at the Content-Warning RFC.

best regards
Christoph


2021-01-09 18:49 GMT+01:00, Erik Wilde <[e-mail]>:
> hello christoph!
>
> welcome to the group! i have nothing to add to the general remarks of
> julian, who is extremely well-versed in all things IETF.
>
> On 2021-01-09 04:10, Christoph Kappestein wrote:
>> I am happy to see some process in this space. Currently we are working on
>> a
>> JSON format called TypeSchema (https://typeschema.org/) which describes
>> JSON
>> payloads and is optimized for code generation.
>
> just as a pointer: https://tools.ietf.org/html/rfc8927 may be
> interesting for you, but i don't know how much overlap there is between
> TypeSchema's goals and JTD.
>
>> We have started this since there is currently no great standard which
>> describes
>> JSON payloads and is optimized for code generation. So if this a topic
>> which you
>> want address I would be happy to share my experiences.
>
> JTD is out there as an RFC, but that of course doesn't mean that it's
> the only way to address this use case. JTD was submitted as an
> individual draft (i.e., not via this group, which didn't yet exist when
> JTD was getting finalized), but i do think that discussing this topic
> might be interesting for this group. but that's just my personal opinion.
>
>> In general we are also working on an open source API management product
>> called
>> Fusio s. https://github.com/apioo/fusio so we are also interested in
>> other
>> standards like i.e. the Deprecation header which we plan to implement,
>> currently
>> we simply issue a standard "Warning" header to inform developers that an
>> API
>> is deprecated, but it is great to see that there is now a dedicated header
>> for
>> this.
>
> that's good to see. if you end up implementing deprecation header
> support, can you please let us know so that we can add your product to
> our list of implementations? thanks!
>
> because of https://datatracker.ietf.org/doc/draft-cedik-http-warning/ i
> am also wondering whether you use warnings for other things as well, and
> if you do, i'd be interested to hear more about it.
>
> thanks and cheers,
>
> dret.
>
> --
> erik wilde | mailto:[e-mail] |
>             | http://dret.net/netdret    |
>             | http://twitter.com/dret    |
>