RE: [csaf] API directions

["Schmidt, Thomas" <thomas.schmidt@bsi.bund.de>]

Dear colleagues,

just one minor remark: I'm in favor of having just one instead of 3 possible solutions as tools have to implement them and we need to test them. So reducing the number of approaches really helps the tool development (and also funding the work).

Nevertheless, I want to echo Stefan's comment on seeking suggestions, comments and contributions regarding the API. As stated during today's meeting, the student that looked into GraphQL as an API solution for CSAF just finished his thesis - it should be published next month.

Best regards,
Thomas

-- 
Thomas Schmidt

From: csaf@lists.oasis-open.org <csaf@lists.oasis-open.org> On Behalf Of Stefan Hagen
Sent: Wednesday, October 25, 2023 7:43 PM
To: csaf@lists.oasis-open.org
Subject: [csaf] API directions

Dear members,

as the meeting was suddenly gone while I was trying to explain where I see 
current points of interest in the development of standardized API(s) for CSAF v2.1
I like to shortly summarize per mail:

1. REST,  GraphQL, and OData to me are potentially all three sustainable as specs 
2. Call for action as which architectural forms of API would your organization be 
1. willing to operate
2. wanting to consume
3. The editors currently prefer in any case a separation of work products a.k.a. documents
1. core spec (the format as successor of the v2.0 spec as it is today)
2. schema files (as of now eventually a different number but linked per the title page of (3.a)
3. new API spec OData / REST / GraphQL presumably in separate docs for themselves (1 to 3) 
4. There is a collecting issue - please feel free to comment there:
1. https://github.com/oasis-tcs/csaf/issues/637

Thanks.

All the best,
stefan.
---
Stefan Hagen, Emmetten, Nidwalden, Switzerland.
read: https://stefan-hagen.website
write: mailto:stefan@hagen.link