-
Notifications
You must be signed in to change notification settings - Fork 1
Structure of API #2
Description
I've been doing some work on the CampFireManager frontend, using CFM2 as the backend. I've noticed a few nuances of the JSON structure in the response that make it hard to work with in places - in particular, the use of objects like so:
{
slot_1: {...},
slot_2: {...}
}
which are, at times a real pain to iterate through (in JavaScript and Python at least) - the order is based on the string value of the index, not the numerical value, so when there's more than 10 items the order of slots is (1, 10, 11, 2, 20, 21...) which is a real pain to work with.
This issue is largely a request that the API return data roughly along these guidelines:
A call to / returns a single object with the configuration - stuff like base url, event name and so on. Anything that would have appeared in the 'SiteConfig' section of CFM2.
A call to '/talk/(id)' returns a talk object containing the obvious needed data and an array of speakers (so the client can run speakers.join(", ") to get a nice comma separated list of speakers).
A call to '/room/(id)' should return the requested room. Ideally this object would have within it an array of all of the sessions, along with whether or not the room is open during that session, and whether it is booked. It could be the case there's a KV pair like so:
talk: false
when there's no talk in the room, and
talk: talkID
or maybe
talk: talkObject
when a talk is scheduled.
A call to '/timetable' should return an array of objects representing sessions, containing the start and end time, and an array of all of the talks occurring at that time. As an example:
{
[
session: {start_time: "10:00:00", end_time: "10:30:00"},
talks: [
{talk_id: 1, title: "A talk about CFM", room: "Room 4"},
{talk_id: 2, title: "Something else", room: "Room 1"}
],
....
]
}
Again, this is just a suggestion and comments are welcome!