IETF Logo Mail Archive

Re: [httpapi] I-D: api-catalog: A well-known URI to help discovery of APIs

Erik Wilde <erik.wilde@dret.net> Thu, 11 May 2023 14:17 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 38617C06F220 for <httpapi@ietfa.amsl.com>; Thu, 11 May 2023 07:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSYoqiZ1jeDs for <httpapi@ietfa.amsl.com>; Thu, 11 May 2023 07:17:56 -0700 (PDT)
Received: from mxout013.mail.hostpoint.ch (mxout013.mail.hostpoint.ch [IPv6:2a00:d70:0:e::313]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2727DC1BE864 for <httpapi@ietf.org>; Thu, 11 May 2023 07:16:38 -0700 (PDT)
Received: from [10.0.2.46] (helo=asmtp013.mail.hostpoint.ch) by mxout013.mail.hostpoint.ch with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.95 (FreeBSD)) (envelope-from <erik.wilde@dret.net>) id 1px75r-0001Vz-75; Thu, 11 May 2023 16:16:31 +0200
Received: from [178.197.203.193] (helo=[172.20.10.8]) by asmtp013.mail.hostpoint.ch with esmtpa (Exim 4.95 (FreeBSD)) (envelope-from <erik.wilde@dret.net>) id 1px75q-0008Bt-W8; Thu, 11 May 2023 16:16:31 +0200
X-Authenticated-Sender-Id: erik.wilde@dret.net
Message-ID: <e65fa541-eff8-099f-fb7f-62869fe9ebf6@dret.net>
Date: Thu, 11 May 2023 16:16:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1
Content-Language: en-US
To: Herbert Van de Sompel <hvdsomp@gmail.com>, Darrel Miller <darrel@tavis.ca>
Cc: "Kevin Smith, Vodafone" <Kevin.Smith=40vodafone.com@dmarc.ietf.org>, "httpapi@ietf.org" <httpapi@ietf.org>
References: <AM5PR0501MB2418A51DEAFA56200C47257391769@AM5PR0501MB2418.eurprd05.prod.outlook.com> <DM6PR01MB5964573BCE01797EA715E333A3779@DM6PR01MB5964.prod.exchangelabs.com> <d7be8263-dba7-e635-f5c0-bcc32ced8ad8@dret.net> <BY5PR01MB59554B48E23470611E439A72A3779@BY5PR01MB5955.prod.exchangelabs.com> <CAOywMHeGCKCLeF9TomGgvW9KeozTGjcUYwOYYCZM0exWs3wFfg@mail.gmail.com>
From: Erik Wilde <erik.wilde@dret.net>
In-Reply-To: <CAOywMHeGCKCLeF9TomGgvW9KeozTGjcUYwOYYCZM0exWs3wFfg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Vs-State: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/5O9-hOnVdD03dB4-60LgGP0Vnwc>
Subject: Re: [httpapi] I-D: api-catalog: A well-known URI to help discovery of APIs
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 11 May 2023 14:17:58 -0000

hello herbert.

On 2023-05-10 16:55, Herbert Van de Sompel wrote:
> The "linkset" relation type is defined and allows for a "profile" 
> attribute that could be used to convey that the target LinkSet is an API 
> catalog.

of course i think that linksets are just wonderful. as a very generic 
format, i am not 100% sure they necessarily would be a great fit for an 
API catalog.

if you wanted to go that route, you could throw in a few of existing 
link relations such as service-desc, service-doc, and service-meta link 
relation types as defined by RFC 8631. if you want a rather minimal API 
catalog, that actually might be an interesting way to go. for something 
a bit richer and more sophisticated, the simplicity of linksets could be 
a bit too limiting.

on the other hand, maybe that would be good enough as an existing and 
standardized media type that could be referenced from the spec. more 
sophisticated media types of course can still be used but there may just 
not be great examples of them out there currently.

cheers,

dret.

-- 
Erik Wilde | mailto:erik.wilde@dret.net    |
            | https://youtube.com/ErikWilde |

v2.46.0 | Report a Bug | By Email | System Status