[Proposal] - API

[mattstauffer]

I've had a (as-yet-private) conversation with a party interested in consuming a REST API from Symposium.

MVP, to me, would be read-only REST-style endpoints for talks, with oAuth2 authentication.

Thoughts? I'll probably spec something out but don't want to go too far into it until we have more conversations.

[mattstauffer]

(ping @adamwathan @dhicking @besologic)

[adamwathan]

Yeah that sounds good to me, I think we need to hammer out exactly how it would work with revisions and versions though, so maybe this is a good time to figure out the best way for that to work.

Re: revisions, what's the goal for those? To be able to revert to a previous version if you realize you don't like the changes you've made?

Re: versions, I think we agreed we might be able to drop these right, and just encourage people to track different talk versions as different talks? I think that would be much simpler all around, even for the end user.

Would we want /talks to return a list of talks with titles (even though that can change per revision) and talk revision IDs, or just the full talk details for the latest revision? I'm tempted to say latest revision makes the most sense vs. exposing revisions as an API resource, or at least using the latest revisions info directly in the talk resource as far as the API is concerned, with a list of revision IDs if you really needed to access a previous revision through the API, but I think we can avoid making that a V1 thing.

I think this is enough to start with...

/users/{id}/talks
/talks/{id}

[mattstauffer]

Yah, I think we dump the concept of showing revisions from the API--it only opens up the latest revision.

As to versions... Ugh. It is time to make that decision for sure.

Revisions is the ability to both see the history, but also to associate a submission (e.g. I submitted talk A to conference B) with a particular revision of the abstract in its history. Which one succeeded, etc.

I think /talks (and the entire API) only hits the current version of each talk. We could open a list of revision IDs on the talk and let that be query able later if we want, but I totally agree.

I agree RE: the endpoints. Assuming we drop versions. which I'm 98% the way to reaching. Let me ponder just a BIT longer...

[adamwathan]

Awesome 👍

Re: versions, what sort of benefits come from keeping it as a real thing? Does it simplify managing your talk proposals at all, like would certain things be able to auto update across all versions saving you repetitive tasks, or anything like that? Or is it purely to "bind" separate talks together under one shared parent just to feel like it's more organized?

The main reason I'm pushing to punt on them at least for now is I think adding another level of drilling down or nesting is gonna hurt the UI a lot.

I would say lets try and see what we can build without them, and wait until it becomes obvious that they are gonna be a killer feature before building them back in?

[mattstauffer]

RE: Versions, chat here: #48
I think it primarily just binds talks together. Can't think of any other benefit.

I think they're super complex for sure. I'm pretty much sold on dropping them.

[rdohms]

Cat is out of the bag.
I have done some prototyping and PoC'ing and the concept works. So I'm working on Pronto! the CfP facilitator. http://rdohms.github.io/pronto/

Regarding the API stuff, yeah all i need is a list of talks and detailed info on them.
If you guys are dropping versions then its even easier for me to integrate that.

Of course Oauth is also something required.

This should be a nice way to take symposium to every single CfP tool, regardless of API's

[mattstauffer]

Getting started in #84 (might be best to finish #82 first but not sure)

[rdohms]

Initial feedback.

So i made a sample json from the talk properties. And tossed it into my filler... we got a good start.
Title and description went right in to OpenCFP. Now i need to work a bit on the notes and other fields.

We may want to think about the talk types and see if we can align them better with the usual options, i'll raise some stats on that.

In general the idea is to take away "most of the work" but still let you manually do a few more tweaked fields, like category, sponsor etc... so we are on the right track.

[mattstauffer]

@rdohms Any news on those talk types?

[rdohms]

@mattstauffer which ones? i was thinking regular, keynote, lightning, workshop.

But i need to go look at all different CfP's for matching types

[mattstauffer]

@rdohms oh, sorry. In an earlier comment you had said "We may want to think about the talk types and see if we can align them better with the usual options, i'll raise some stats on that." Just wanted to see if you had a normalized list that you liked. :)

[rdohms]

not yet, i was away for a week on vacation/conference with "please kill me" wifi only.. i'll get back to raising this.

[mattstauffer]

@rdohms haha no stress at all! :)

[mattstauffer]

Completed via #84