GET /advisories

[carlosthe19916]

Hi tried to put my hands into generating REST endpoints for the advisories. Some questions came to my mind:

• Do we really need the following data inside the Paginated Object?

pub num_pages: u64,
pub prev_page: Option<Paginated>,
pub next_page: Option<Paginated>, 

From the REST point of view, whoever is making a request can infer all those 3 fields based on data being send and the first response of the server.

• At the moment, we save (in the DB) limited data about Advisory . We will definitely need to extract more fields out of the CSAF files. I could not find any code where we are extracting data from CSAF files and then map them to the DB or object. Is something like that already existing somewhere or it needs to be implemented?

pub struct Model {
    #[sea_orm(primary_key)]
    pub id: i32,
    pub identifier: String,
    pub location: String,
    pub sha256: String,
}

I'm not expecting this PR to be merged as it does not contain the fields I expect to expose through the REST endpoints, but I just wanted to open this PR for my questions to make more sense.

[carlosthe19916]

Or perhaps starting on "Advisories" was a bad idea as other abstractions like "Packages", "CVEs", "SBOMs" might be better implemented at the moment? xD

[bobmcwhirter]

We can certainly modify how pagination works. That was mostly a spike for me to understand how SeaORM handles paginating, along with my own ignorance of what's needed on the front-end. I somewhat come from the school of HATEOAS, and generally prefer for links to be sent within the response, instead of the client having to calculate and construct URLs from patterns.

But that's not a strongly-held opinion.

[bobmcwhirter]

ref: https://en.wikipedia.org/wiki/HATEOAS

[carlosthe19916]

We can certainly modify how pagination works. That was mostly a spike for me to understand how SeaORM handles paginating, along with my own ignorance of what's needed on the front-end. I somewhat come from the school of HATEOAS, and generally prefer for links to be sent within the response, instead of the client having to calculate and construct URLs from patterns.

But that's not a strongly-held opinion.

Certainly for a UI is better to rely on itself to create URLs. However, the REST API and the functions within the backend should not consider the UI as the only/unique consumer but also consider other potential consumers of the REST API (like terminals, or anything else that comes to our mid). So having HATEOAS sounds good.

I'll close this PR as I also found the block of code I was searching: https://github.com/trustification/trustify/blob/main/importer/src/csaf/mod.rs#L129 this is where files start their journey to be ingested/processed/stored