Open hemebond opened 4 years ago
Pleeeaaase use the schema I designed. :]
authors, game, releasedate, title, urls etc better all be tags, not keys in the main dict. Otherwise we end up with a structure that is too restrictive. We need a flexible structure and a simple key=value list is something that would be future-proof. We should try to cram as much into that as possible, using subnamespaces (namespace:subnamespace=value) if needed.
The API can have multiple versions, but why is this structure more restrictive? Using key=value
just means having to manually parse it out the values rather than using a JSON parser to do it all.
The other structure also mixes file attributes amongst the package attributes and has Markdown embedded in values.
Because we have no idea what keys we might need and I would like to not require a new schema version if we just want to add another tag.
Only the filename and known download URLs are in the main attributes in my schema, true those could also be moved to tags, maybe they should?
The markdown for links was basically a "we have titles for links, let's include them somehow", not much would be lost if we only had the URLs. Or we could use "link:review=...", "link:homepage=...", "link:func=---" and every user of the data could decide which info they'd use from there.
This is not what the website would be importing, this is an API the website would expose for third-parties to get information about packages.
It would be up to the consumer to handle missing attributes, e.g., empty or missing urls
.
Please provide an additional endpoint to get filtered results. It doesn’t need to be a complex search with multiple attributes - a simple “title startswith ‘specified_parameter’ ”, a la web browser search, should suffice. Make it a caseless search and we’ll have a winner.