[p3t] [EXTERNAL] Draft documents demonstrating standards layout

[Kim Gillies]

Hi All,

There is “Smithy”, which is a https://smithy.io/2.0/index.html, which is similar to what is being discussed.  I do not have direct experience with it, and maybe it was discussed and rejected, but it is open source, mature, and supports many programming languages, etc.  The following is from: https://smithy.io/2.0/guides/model-translations/converting-to-openapi.html

Kim

Differences between Smithy and OpenAPI

Smithy and OpenAPI take very different approaches to modeling APIs. Smithy is protocol agnostic, which means it focuses on the interfaces and abstractions that are provided to end-users rather than how the data is sent over the wire. While Smithy can define RESTful APIs, RPC APIs, pub/sub APIs, and more, OpenAPI only defines RESTful APIs. Both approaches have their own strengths and weaknesses. For example, while Smithy can define a much broader set of functionality, services, and client behaviors, it requires abstractions that have their own underlying complexity. OpenAPI is more permissive in the kinds of services it can describe, making it easier to adapt to existing web services, but at the same time making it easier to author APIs that provide a poor customer experience when using clients in strongly-typed languages.

> On Aug 30, 2024, at 4:04 AM, Paul Harrison via p3t <p3t at ivoa.net> wrote:
> 
> 
> 
>> On 29 Aug 2024, at 18:59, Russ Allbery <eagle at eyrie.org> wrote:
>> 
>> My larger concern is that I am dubious that OpenAPI will prove to be
>> resilient against future changes to prevailing protocols and definition
>> languages any more than XML schemas were.  gRPC does not use OpenAPI, for
>> example; it uses protobuf as its API definition language.  I fear that
>> OpenAPI is a specification language for this one particular moment in
>> time, and in the future people will use something else, similar to how XML
>> schemas used to be common and now, although they still exist, they're less
>> widely used.
>> 
>> That said, designing a specification language is an immense amount of
>> work, and I don't want us to write our own either.  We should use OpenAPI
>> today because that's what people use today.  But I would like to have some
>> sort of semantic language specific to the IVOA, ideally one with a minimum
>> amount of additional formality so that it's easy to read and easy to
>> write, that nails down all the things that OpenAPI may leave ambiguous and
>> provides enough additional information that we can adapt our data types to
>> some new language that comes along later.
>> 
> 
> Designing a general purpose specification language is a lot of work - however, all we *need* is a language to describe
> interfaces that follow IVOA patterns, so that it does not have to be that extensive. So for example when the 
> hypothetical IVOA interface language says for example “return error” it can be transformed into the IVOA pattern in OpenAPI that
> expresses the way to return an error. So that a lot of the “detail” that makes OpenAPI complex is removed by having conventions.
> 
> Paul.
> 
> -- 
> p3t mailing list
> p3t at ivoa.net
> http://mail.ivoa.net/mailman/listinfo/p3t

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/p3t/attachments/20240830/2005fc42/attachment.htm>