Open-event-server: Implement speakers api with proper permissions and relationships

[LuD1161]

Proposed API structure :

/speakers/ : get all speakers
/speakers/<int:event_id> : get speakers for one event

[niranjan94]

@LuD1161 this is not how JSON-API Spec compatible APIs are implemented. Why haven't you read about it yet ? Please read up on the JSON-API Specification.

The endpoints needed should be like this. (the below list may not be complete. But you get the idea)

• /speakers/int:id/event
• /events/int:event_id/speakers
• /events/int:id/relationships/speakers
• /speakers/int:speaker_id/sessions
• /sessions/int:id/relationships/speakers
• /speakers
• /speakers/int:id
• /speakers/int:id/relationships/event

[LuD1161]

@niranjan94
Thanks for the descriptive info.
It's not that I haven't read about JSON-API specification. I was going to implement relationships and other details. I forgot to mention more at the end.
I hadn't thought of all the endpoints till then so didn't mention it.
Will add other endpoints as I progress.
Thanks.

[SaptakS]

Isn't this the same issue as #3591? @niranjan94 @LuD1161

[niranjan94]

@enigmaeth most of this has already been done by @LuD1161 . You can find the code over here in this branch (https://github.com/fossasia/open-event-orga-server/tree/speakers-api). Please work on that branch.

You can see what is left out in the comments over at #3771 .

[enigmaeth]

@niranjan94 @SaptakS @shubham-padia

Please take a look at details for Speakers API. Please correct if I am wrong at any point.

From #3771, I got the following:

• One user can be related to multiple speaker profiles.
• One session is related to one speaker. And one speaker is related to one session. (Conflicting endpoints, please confirm)
• One session can have many speakers. One speaker can have many sessions.

Proposed Endpoints:

• speakers/<int:id> : To get details of one speaker profile by id

• speakers/<int:id>/session : Get the details of session where this speaker profile is speaking

• speakers/<int:id>/sessions : Get the list of sessions where this speaker profile is speaking
• speakers/<int:id>/event : Get the details of event where this speaker profile is speaking

• speakers/<int:id>/user : Get the details of user with which this speaker profile is associated

• events/<int:event_id/identifier> : To post the details and to get list of speakers for an event

• sessions/<int:session_id>/speaker : Detail of speaker of that session
• sessions/<int:session_id>/speakers : List of speakers of that session
• users/<int:user_id>/speakers : List of speaker profiles associated with that user

Plus the corresponding relationship endpoints.

Do these look good? Suggestions please!

[niranjan94]

One user can be related to multiple speaker profiles.

Correct.

One session is related to one speaker. And one speaker is related to one
session.

No. This should be many to many. One session can have many speakers. One
speaker can have many sessions.

On Thu, Jul 6, 2017, 1:58 AM Afroz Ahamad [e-mail] wrote:

@niranjan94 https://github.com/niranjan94 @SaptakS
https://github.com/saptaks @shubham-padia
https://github.com/shubham-padia

Please take a look at details for Speakers API. Please correct if I am
wrong at any point.

From #3771 https://github.com/fossasia/open-event-orga-server/pull/3771,
I got the following:

• One user can be related to multiple speaker profiles.
• One session is related to one speaker. And one speaker is related to
  one session. (Conflicting endpoints, please confirm)

Proposed Endpoints:

-

speakers/ : To get details of one speaker profile by id
-

speakers//session : Get the details of session where this
speaker profile is speaking
-

speakers//event : Get the details of event where this speaker
profile is speaking
-

speakers//user : Get the details of user with which this
speaker profile is associated
-

events/ : To post the details and to get list
of speakers for an event
-

sessions//speaker : Detail of speaker of that session
-

users//speakers : List of speaker profiles associated
with that user

Plus the corresponding relationship endpoints.

Do these look good? Suggestions please!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fossasia/open-event-orga-server/issues/3727#issuecomment-313217374,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACSwFEVCX3Rs7bDIvO0BbLXtdBXeFgF_ks5sK_HWgaJpZM4NvvAb
.

[arp95]

also guys i cam across an event where a session can belong to multiple tracks. are we going to handle such a case?

[niranjan94]

Nope. I guess you're talking about FBF8. Those weren't actually tracks.
There were more like categories/topics/tags.

As far as tracks go, one session can only belong to one track. That's what
a track is.

We may support categories/topics/tags like that FBF8 in future. But no
plans for that at this point.

On Thu, Jul 6, 2017, 10:13 AM Arpit Aggarwal [e-mail]
wrote:

also guys i cam across an event where a session can belong to multiple
tracks. are we going to handle such a case?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fossasia/open-event-orga-server/issues/3727#issuecomment-313293600,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACSwFFM4049S0Bo1zWuzYSNyIT-lMjQTks5sLGX6gaJpZM4NvvAb
.

[arp95]

actually i was talking about the google io case.
Link: https://events.google.com/io/schedule/?section=may-17&sid=5f387420-d89d-46d4-b5af-f740e59a52cb

in this case the session belonged to the firebase and cloud track.
yeah sure no problem. i just came across so notified you guys,

[enigmaeth]

@SaptakS @niranjan94 @shubham-padia

We have
events/id/speakers endpoint for get and post
speakers/id : get details, patch, delete

about the other endpoints, I think that providing post is a bad idea as we don't want to add speakers there, rather we just want to add relationships, so only get seemed logical to me for:
sessions/id/speakers
users/id/speakers

Here's the commit with the endpoints implemented from my comment above

[niranjan94]

@enigmaeth We need the following.

• GET/POST /v1/events/<identifier>/speakers - Get/Create a speaker(s) related to event.
• GET/PATCH/DELETE /v1/speakers/<id>
• GET/POST /v1/speakers/<id>/sessions - Get/Create a session(s) related to speaker.
• GET/POST /v1/sessions/<id>/speakers - Get/Create a speaker(s) related to session.
• GET/POST /v1/users/<id>/speakers - Get/Create a speaker(s) related to user.
• GET /v1/speakers/<id>/user - Get user linked to speaker

Relationships can be adding in the PATCH /v1/speakers/<id> request itself anytime. (See http://jsonapi.org/format/#crud-updating-resource-relationships )