IETF Logo Mail Archive

Re: [httpapi] Introduction

Erik Wilde <erik.wilde@dret.net> Sat, 09 January 2021 17:49 UTC

Return-Path: <erik.wilde@dret.net>
X-Original-To: httpapi@ietfa.amsl.com
Delivered-To: httpapi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296CC3A13E3 for <httpapi@ietfa.amsl.com>; Sat, 9 Jan 2021 09:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level:
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZzIXiHoxa4M for <httpapi@ietfa.amsl.com>; Sat, 9 Jan 2021 09:49:33 -0800 (PST)
Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E043A13E2 for <httpapi@ietf.org>; Sat, 9 Jan 2021 09:49:33 -0800 (PST)
Received: from [108.205.51.24] (port=52691 helo=dretpro.attlocal.net) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <erik.wilde@dret.net>) id 1kyIMl-0006mZ-47; Sat, 09 Jan 2021 12:49:31 -0500
To: Christoph Kappestein <christoph.kappestein@gmail.com>, httpapi@ietf.org
References: <CALcRZn4YSC9w4VA7J=UfEoUrKDLwfoTTU38GHA5CQ9xdHVPDhA@mail.gmail.com>
From: Erik Wilde <erik.wilde@dret.net>
Message-ID: <f5442133-47fd-f9a2-77e5-fd9a1548729b@dret.net>
Date: Sat, 09 Jan 2021 09:49:27 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <CALcRZn4YSC9w4VA7J=UfEoUrKDLwfoTTU38GHA5CQ9xdHVPDhA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dret.net
X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net
X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/b-zFWJEV-H3CTt8y91K2qww-eAE>
Subject: Re: [httpapi] Introduction
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/httpapi>, <mailto:httpapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi/>
List-Post: <mailto:httpapi@ietf.org>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpapi>, <mailto:httpapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jan 2021 17:49:35 -0000

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:erik.wilde@dret.net |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

v2.23.0 | Report a Bug | By Email