Introduction
This page describes an alternative flow to the one described in Limiting concurrent media streams
Alternatively to the flow described in the example above, the session ID can be defined by the client by using the PUT endpoint. This allows client to use an existing globally unique identifier such as a device ID as session ID, rather than storing the session ID returned by the API.
Alternative concurrent media streams limitation flow
The alternative flow works the same as the standard flow, except that when a new session is created, the client calls the API with a PUT request to the following endpoint: Media play sessions#/Media%20Play%20Sessions/putMediaPlaySession
Example:
curl -X PUT \
'https://demo.aminocom.com/api/v1/media/users/{user_id}/media_play_sessions/{media_play_session_id}' \
-H 'Authorization: Bearer xxxxx.yyyyyy.zzzzz'
The session is then kept alive either by repeatedly calling the same endpoint with the same PUT request, or by the standard PATCH method as described in the standard flow.
When the user stops watching the media, the client is expected to call the DELETE endpoint as per the standard flow.
In case client fails to call the DELETE endpoint, session will remain and expire eventually, until it does the user will have one less session available for use. The default expiration time is 2 hours.
Error cases
As with the standard flow, the API responds with errors when the session limit is reached or there are authentication errors.
The session ID must be globally unique, so if the client attempts to create a new session through a PUT request and it already exists for some other user, then the API will respond with a 404 - Not found error.
If the API is called with a PUT request for a session ID that already exists, but the body of the request contains a device type that conflicts with the previously created session, then the API will respond with a 409 - Conflict error.