68
edits
Loop/Architecture/Rooms: Difference between revisions
Merge both /room-url and /rooms endpoint since they both describe the same rooms concept. We don't have multiple room for the same /room-url.
(Merge both /room-url and /rooms endpoint since they both describe the same rooms concept. We don't have multiple room for the same /room-url.) |
|||
| Line 1: | Line 1: | ||
Based on early user feedback, we will be adding [https://people.mozilla.org/~dhenein/loop/rooms/ a "rooms" metaphor] to the Loop product. Initially, this will be based on a "link as a room" model, although we will likely explore link-free rooms experiences for logged-in users in the future. | Based on early user feedback, we will be adding [https://people.mozilla.org/~dhenein/loop/rooms/ a "rooms" metaphor] to the Loop product. Initially, this will be based on a "link as a room" model, although we will likely explore link-free rooms experiences for logged-in users in the future. | ||
Many of the network operations required for rooms are very similar to those we currently use for link-based calling (that is, the "/call-url" and "/calls" endpoints). However, the parameters and behaviors are sufficiently different that re-using those codepaths would have caused more confusion and work than simply defining new ones. However, the conceptual model that developers have around how these endpoints work can be useful in understanding the rooms design. Consequently, the network API for rooms uses | Many of the network operations required for rooms are very similar to those we currently use for link-based calling (that is, the "/call-url" and "/calls" endpoints). However, the parameters and behaviors are sufficiently different that re-using those codepaths would have caused more confusion and work than simply defining new ones. However, the conceptual model that developers have around how these endpoints work can be useful in understanding the rooms design. | ||
Also in the case of Rooms there is no such thing as a call, rooms are always open so that people can enter them at any times. | |||
Consequently, the network API for rooms uses the "/rooms" endpoint. | |||
Note, however, that no websockets connection is necessary, as call progress information is not conveyed. | |||
Similar to the call-url design, users can generate rooms both when logged in to FxA and when not logged in. | Similar to the call-url design, users can generate rooms both when logged in to FxA and when not logged in. | ||
| Line 14: | Line 19: | ||
|- | |- | ||
| Thu Sep 11 19:28:32 UTC 2014 || Adam Roach || Updates after initial feedback: now uses multiple push URLs. Renamed "operation" to "action" to be consistent with other loop-server endpoints. | | Thu Sep 11 19:28:32 UTC 2014 || Adam Roach || Updates after initial feedback: now uses multiple push URLs. Renamed "operation" to "action" to be consistent with other loop-server endpoints. | ||
|- | |||
| Tue Sep 23 16:23:51 UTC 2014 || Rémy Hubscher || Merge /rooms and /room-url endpoints since they describe the same /rooms concept. i.e: We don't have multiple rooms for the same /room-url as we have multiple /calls for the same /call-url | |||
|} | |} | ||
| Line 146: | Line 153: | ||
To accommodate rooms, the Loop Server API will need the following additions. | To accommodate rooms, the Loop Server API will need the following additions. | ||
=== POST / | === POST /rooms === | ||
This generates a new room and returns the associated URL that can be used to join the room. | This generates a new room and returns the associated URL that can be used to join the room. | ||
POST / | POST /rooms HTTP/1.1 | ||
Accept: application/json | Accept: application/json | ||
Accept-Encoding: gzip, deflate | Accept-Encoding: gzip, deflate | ||
| Line 186: | Line 193: | ||
''Server implementation note: The Loop server should contact the TokBox servers and retrieve a sessionId for the room at room creation time. This sessionId should be stored persistently with rest of the information associated with the room.'' | ''Server implementation note: The Loop server should contact the TokBox servers and retrieve a sessionId for the room at room creation time. This sessionId should be stored persistently with rest of the information associated with the room.'' | ||
=== PUT / | === PUT /rooms/{token} === | ||
The "PUT / | The "PUT /rooms/{token}" endpoint is used to update information about an existing room. | ||
PUT / | PUT /rooms/_nxD4V4FflQ HTTP/1.1 | ||
Accept: application/json | Accept: application/json | ||
Accept-Encoding: gzip, deflate | Accept-Encoding: gzip, deflate | ||
| Line 201: | Line 208: | ||
} | } | ||
The parameters for this endpoint are the same as for "POST / | The parameters for this endpoint are the same as for "POST /rooms". Any omitted parameters are not updated. | ||
HTTP/1.1 200 OK | HTTP/1.1 200 OK | ||
| Line 215: | Line 222: | ||
* '''expiresAt''' - The date after which the room will no longer be valid (in seconds since the Unix epoch). | * '''expiresAt''' - The date after which the room will no longer be valid (in seconds since the Unix epoch). | ||
=== DELETE / | === DELETE /rooms/{token} === | ||
Destroys a previously-created room. | Destroys a previously-created room. | ||
DELETE / | DELETE /rooms/_nxD4V4FflQ HTTP/1.1 | ||
Accept: */* | Accept: */* | ||
Accept-Encoding: gzip, deflate | Accept-Encoding: gzip, deflate | ||
| Line 407: | Line 414: | ||
* '''ctime''' - Similar in spirit to the Unix filesystem "ctime" (change time) attribute. The time, in seconds since the Unix epoch, that any of the following happened to the room: | * '''ctime''' - Similar in spirit to the Unix filesystem "ctime" (change time) attribute. The time, in seconds since the Unix epoch, that any of the following happened to the room: | ||
** The room was created | ** The room was created | ||
** The owner modified its attributes with "PUT / | ** The owner modified its attributes with "PUT /rooms/{token}" | ||
** A user joined the room | ** A user joined the room | ||
** A user left the room | ** A user left the room | ||