Open-event-server: Better options for APIs

[mariobehling]

Currently the API endpoints are implemented for the single APIs. This option is not user friendly. Please research, propose and implement a better way. Think of examples of APIs at Twitter and Facebook.

• [ ] How can we bundle API access?
• [ ] Which API access should stay separate?
• [ ] How should and can we limit access e.g. with keys for events

[niranjan94]

@mariobehling I'm not exactly clear what you mean by single APIs and bundled APIs. I have answered below, according to my understanding of it. If it's not what you meant, could you please explain ?

---

How can we bundle API access?

The API endpoints are already bundled. All the event related endpoints like session, microlocations, tracks etc come under /api/v2/events/{event_id}/.

Which API access should stay separate?

User API is separate. In future, if we are adding an API for settings, that will also be separate.

How should and can we limit access e.g. with keys for events

All the CUD (Create, update, delete) operations are already limited to our existing access control definitions. For CUD operations, JWT key is used for authentication.

[SaptakS]

I agree with @niranjan94. I feel the APIs are already bundled according to the API schema created. @mariobehling I did some digging into twitter API page and found this . It has an example and parameter descriptions but I couldn't understand what you meant by bundling. Can you please guide? Thanks.

[mariobehling]

Currently we have all kinds of APIs listed. How can we have a user friendly way how developers can access our data?

[SaptakS]

@mariobehling so we need to get all the similar APIs bundled under main categories like Microlocation, Sessions, etc. right?

[shivamMg]

@mariobehling

How can we bundle API access?
Which API access should stay separate?

Could you please elaborate more on these two.

How should and can we limit access e.g. with keys for events

I think you mean limiting API usage to developers. Like letting them make maximum X requests in Y time period. Or let them make requests per plan basis, like X requests for plan A, Y for plan B, etc.

[mariobehling]

@niranjan94 In order to get access to the event data, how many steps do I need? Is there a way to get the api access to all apis through one string?

[niranjan94]

To get the event data (without sessions, tracks, microlocations), one request to
/api/v2/events/<event_id> is required

[SaptakS]

@mariobehling @niranjan94 yes, request to /api/v2/events/<event_id> gives us the data for the event along with the track_id, microlocation_id, etc. as well.

[mariobehling]

@SaptakS @niranjan94 So, this means we could just define "/api/v2/events/" as a link to access all event data? Or how can we make it easy for devs?

[SaptakS]

@mariobehling this link is already there to provide data for all events. If you want that the dev should get all the data for sessions, microlocations, etc. related with the event in a single API call then we can use an url like api/v2/events/<event_id>/all . But I don't know if that is feasible.

[mariobehling]

@SaptakS Sounds good. We only need to think about private data e.g. speaker info with mobile numbers etc.. But we can go into this in a follow up issue. How can we get the one API string to work?

[SaptakS]

@mariobehling this is actually something which people usually don't do. People tend to keep different APIs for different feature with only some basic information about the feature being given. Like we provide microlocation id and name while not giving any other info about microlocation when we go to api/v2/events/<event_id>/. So that is what is mostly done. But, yes, if you want this can be done as well and we can decide on which all information we want to share and which we don't.

Youtube has a similar API and names it as Bulk Reporting Api. So we can maybe go with Bulk Event API name with an endpoint api/v2/events/<event_id>/bulk.

@niranjan94 what do you think?

[niranjan94]

I don't think creating new endpoints for this is a good idea. One thing that i have seen in many APIs is using a query string parameter to tell what all data is required.

Examples:

1. /api/v2/events/<event_id>/ - will display basic event info _(what we already have right now)_
2. /api/v2/events/<event_id>/?include=sessions - will include all the sessions along with the basic event data.
3. /api/v2/events/<event_id>/?include=sessions,speakers - will include all the sessions and speakers info along with the basic event data.
4. /api/v2/events/<event_id>/?include=tracks - will include all the tracks info along with the basic event data.

Like this the user can specify what all additional data he/she requires when calling the event API. This way, with a single request all the required data is obtainable.

I strongly believe that this is the right way to do this. Not creating new endpoints. This also more _customizable_ for the user as he/she is able to specify what all data is required.

@SaptakS @mariobehling your opinions ?

[SaptakS]

@niranjan94 that sounds better I think. @mariobehling what do you think?

[mariobehling]

@niranjan94 Ok, great. Could we have an interface to click this together? Please open an issue for this implementation and close this one.

[SaptakS]

@niranjan94 @mariobehling will create an issue.

[SaptakS]

Implementation - #1733