Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API #4

Open
2 of 3 tasks
hemebond opened this issue Dec 28, 2019 · 6 comments
Open
2 of 3 tasks

API #4

hemebond opened this issue Dec 28, 2019 · 6 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@hemebond
Copy link
Owner

hemebond commented Dec 28, 2019

  • Add thumbnail/screenshot to the package list
  • allow fetching maps uploaded after a time
  • add start map to model
@hemebond hemebond added the documentation Improvements or additions to documentation label Dec 28, 2019
@hemebond hemebond self-assigned this Dec 28, 2019
@SpiritQuaddicted
Copy link

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.

@hemebond
Copy link
Owner Author

hemebond commented Dec 28, 2019

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.

@SpiritQuaddicted
Copy link

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.

@hemebond
Copy link
Owner Author

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.

@hemebond
Copy link
Owner Author

@Izhido
Copy link

Izhido commented Sep 18, 2020

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.

@hemebond hemebond pinned this issue Sep 21, 2020
@hemebond hemebond changed the title JSON API structure API Nov 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants