search

HUPO-PSI / proxi-schemas

ProXI: Schema definitions for the Proteomics eXpression Interface
3 stars 3 forks source link

Spectra end-point with no filter should be avoid #45

Open ypriverol opened 4 years ago

ypriverol commented 4 years ago

The spectra endpoint contains three possible filters: usi, accession, scan, file collection

However, we never defined that at least one of them should be defined for the query. Then, the following query is possible:

http://www.peptideatlas.org/api/proxi/v0.1/spectra?pageSize=100&resultType=compact&responseContentType=json

In practical terms we shouldn't allow this because no many users will loop in the entire resource to get all the spectra.

Opinions?

edeutsch commented 4 years ago

In my opinion it can be up each individual resource what queries they can honor and which they can decline as too unconstrained. If MassIVE has an indexed set of a billion spectra and they will let users execute that query, fine. At PeptideAtlas, we will likely return an error that an unconstrained query is not supported. My main interest is we're all using the same language, not to insist on what subset of options must be supported. At the moment, we only support a USI-based query. We can alternatively support accession, file, scan if all provided as a trio, although we haven't hooked that up yet. I think it would also be useful to specify a peptidoform ion as a query parameter, so you could ask for all spectra corresponding to a particular ion. Although that is not yet in the spec. I think it should be eventually.

But I suppose the near term goal is to see what the various resources can easily support and compare notes.

ypriverol commented 4 years ago

In my opinion it can be up each individual resource what queries they can honor and which they can decline as too unconstrained. If MassIVE has an indexed set of a billion spectra and they will let users execute that query, fine. At PeptideAtlas, we will likely return an error that an unconstrained query is not supported. My main interest is we're all using the same language, not to insist on what subset of options must be supported. At the moment, we only support a USI-based query. We can alternatively support accession, file, scan if all provided as a trio, although we haven't hooked that up yet. I think it would also be useful to specify a peptidoform ion as a query parameter, so you could ask for all spectra corresponding to a particular ion. Although that is not yet in the spec. I think it should be eventually.

Ok, we just need to make sure that even if a parameter or query is possible by definition, then the specific implementation can reply no implemented error code as we defined for the things that the specific service do not support.

But I suppose the near term goal is to see what the various resources can easily support and compare notes.

Agree

chambm commented 4 years ago

I think the schema should mandate that implementers support a subset of filters, and optionally support more advanced ones. There should also be a mandatory endpoint for returning which filter combinations are supported, so that clients don't have to blunder around trying different filters like I just did 30 minutes ago trying to figure out what was supported (apparently nobody supports retrieving by accession only right now). Beyond that, I propose that implementers should have to support returning USI spectra individually. And perhap they should also have to support returning entire datasets by accession (probably not supporting it with JSON but some binary serialization or even just sending a list of URLs of files to download). Having a common language for requesting an entire dataset seems very useful to me.

Returning all spectra for a particular ion should be under the /psms endpoint, right?