-
-
Notifications
You must be signed in to change notification settings - Fork 429
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
Question about API formatting #1047
Comments
Hi @rdegges, |
No problemo! I'm currently doing that, was just curious if you were all interested in potentially accepting some changes to tweak the formatting a bit, but no worries at all. Thanks for the great project! =D |
Hi, Do u think you can open source in this repository your integration? (maybe it can help people) Moreover, if Snyk use it, I think it could be a good idea to sponsor this repository in order to support this project :). |
Hi, |
Hi there! Really love this project =D
I work at Snyk and am currently building an integration with your API to help us find events we might want to speak at/sponsor/etc. This is really nifty!
As I've been diving into this a bit more, I have a generic question (sorry if this isn't the best place for it).
I'm primarily using the all-events JSON endpoint: https://developers.events/all-events.json
The format of event entries returned by the API looks like this today:
Here's my question: would you be open to potentially changing this format in the future or potentially adding a v2 all-events.json endpoint that allows for some additional formatting? For example, it would be really neat if we could get events back in a format like the following:
There are a few key changes here:
date
array field with UTC timestamps has been changed to an object with "start" and "end" attributes that are strings with YYYY-MM-DD formatting. This is handy since, from what I can tell, no events include specific hour/minute/second/ms info so it's easier to parse/work with.hyperlink
field has been renamedurl
for consistency (more info below)country
field now uses standard country codes (two letters) for more easy parsability. This way it uses the ISO country codes.cfp.link
field has been renamedcfp.url
for consistency (this way, all URLs are referred to with the same field name)cfp.until
field has been renamedcfp.end
for consistency with dates abovecfp.end
field uses the same date formatting as above: YYYY-MM-DDstatus
field includes the status in ALL_CAPS and only allows for an enum of options. For example, this might include statuses like: "OPEN", "DONE", "DELAYED", "CANCELED", ... But having these standardized would make it easier to parse/work with, since right now statuses look a tiny bit inconsistent, e.g., "open", "Virtualized", "Canceled", etc.I'd be happy to contribute, but am curious what your thoughts are on the approach above, if it even makes sense, etc. Thanks for your time! <3
The text was updated successfully, but these errors were encountered: