You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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:
The 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.
The hyperlink field has been renamed url for consistency (more info below)
The country field now uses standard country codes (two letters) for more easy parsability. This way it uses the ISO country codes.
The cfp.link field has been renamed cfp.url for consistency (this way, all URLs are referred to with the same field name)
The cfp.until field has been renamed cfp.end for consistency with dates above
The cfp.end field uses the same date formatting as above: YYYY-MM-DD
The status 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:
Hi @rdegges,
The endpoint is managed entirely by the community. Thus, I would suggest that in the meantime you create a script to reformat the v1 structure to your liking.
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.
Hi,
I'm curious about what u said:
"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!"
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 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: