- From: Edgard Marx <marx@informatik.uni-leipzig.de>
- Date: Mon, 26 Apr 2021 18:37:54 +0200
- To: Antonin Delpeuch <antonin@delpeuch.eu>
- Cc: public-reconciliation@w3.org
- Message-ID: <CALhcugm6anQSoKARUVCeJz60_tENOE8QRNnJV1M+NMW_YB0uzg@mail.gmail.com>
Tanks for you fast reply. I will try to answer inline: On Mon, Apr 26, 2021 at 2:03 PM Antonin Delpeuch <antonin@delpeuch.eu> wrote: > Hi Edgar, > > Thanks for this pointer to the OpenAPI specs, that is something worth > taking inspiration from. > > Also, the broader idea of aligning the reconciliation API to OpenAPI, or > more generally to make it more "RESTful", is definitely something that has > been proposed in the past and seems to gather some interest: > > https://github.com/reconciliation-api/specs/issues/17 > > The main concern I have is whether we can do this in a backwards > compatible way, and if not, is the breaking change worth it? > I guess the answer is yes, giving that is highly adopted API. It also does not influence the interface definition, but rather gives a standardisation on how to define arguments, reference, and document them. In my opinion, deprecate APIs to follow standards are not necessarily a bad thing to do. > Also it is not clear to me what you mean by "avoid reworking other groups' > specs" - I don't see why that would happen? > Specifically, which spec are you worried that the reconciliation CG would > try to rework? > Or is it another group that could want to rework the reconciliation API? > In your example, it is clear to me that we are not following the openAPI specification and there was a doubt in what direction to go. Here I suggest not using '$' nor {{}} but what defines the openAPI spec ->* {} *. I also suggest to apply the whole openAPI spec gradually in the future Reconcile APIs to come. merci, Edgard > Best, > > Antonin > On 26/04/2021 00:32, Edgard Marx wrote: > > Hi Antonin, > > Glad you asked. > I am quite new to the group, so please excuse me if I am talking nonsense. > In case you already have discussed this issue before. > > It is in my opinion that one should avoid reworking other groups' specs. > Particularly if it is not the aim of the working group. > Having that in mind, it will be nice if the Reconcile API is built on top > of the OpenAPI (https://github.com/OAI/OpenAPI-Specification) specs. > Especially because it has broader acceptance and adoption (e.g. Daimler > Mobile data API). > In this particular case, the OpenAPI specifies the use of simple brackets > e.g. {variable} ( > https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#path-templating > ). > > kind regards, > <emarx/> > http://emarx.org > > > On Fri, Apr 16, 2021 at 5:58 PM Antonin Delpeuch <antonin@delpeuch.eu> > wrote: > >> Hi all, >> >> One area where we could make some progress is the URL templates exposed >> by the manifest: >> https://github.com/reconciliation-api/specs/issues/39 >> >> Beyond the fact that the template variable is not consistent across the >> whole manifest, the escaping of the value it is replaced with remains to >> be specified. The problem is that both behaviours (escaping or not) can >> potentially be useful in some contexts. >> >> Any thoughts about how to specify this better? >> >> Best, >> Antonin >> >>
Received on Monday, 26 April 2021 16:38:25 UTC