Gurukul My Project Guide

The goal is to create generic and yet simple APIs for variety of access protocols in our system: HTTP, XMPP, RTMP and SIP. Modern web applications are using RESTful APIs for scalability, robustness and re-use of existing techniques. A web-based Flash application client can use HTTP and RTMP whereas traditional client applications can use their own standard protocol such as XMPP and SIP. While a Flash application can also use XMPP, there are a number of features that we want to support and are not available in pure XMPP. Hence HTTP is needed anyway. To keep the web application simple, our web-based client will only use HTTP and RTMP.

In our system the HTTP-based interface will follow RESTful architecture. The server will expose some resources, which can be accessed by the client. For example, /user represents the collection of registered users, /login represents the currently logged in users, and /call represents the multimedia conferences. One can do POST /user to create a new user account, and GET /call/1234 to get information about a particular call.

Pure RESTful request-response API is not enough for event-based applications such as ours. For example, it is difficult to convey the server-initiated events such as new incoming call request to the client. Other protocols such as XMPP already has mechanism to do this. Additionally, techniques such as bidirectional stream (BOSH) are available to facilitate asynchronous events over HTTP, as well as to allow XMPP over HTTP to traverse firewall and NAT. Because of the benefits of BOSH, we reuse it in our system as well.

XMPP, SIP and RTMP allow asynchronous event subscription and notification primitives, whereas HTTP does not. Our system will incorporate a novel HTTP-based event subscription and notification technique. A client can subscribe to any resource and will receive notification when someone posts a change to that resource. Besides the implicit notification on change, someone can explicitly send a notification for that resource.

User Signup: The user account creation and deletion should be outside the system, so that it doesn’t suffer from the account creations by spammers, and allows easy integration with existing user accounts. Techniques such as visual CAPTCHA, email verification, invitation only and/or moderator approval can be available to slow down spam account creators. Many potential users of the system will already have account else where, hence third-party authentication should be supported, e.g., Google AuthSub, OpenID, Open Social, etc.

The RESTful API defines /user resource to represent the list of signed-up users, which you can POST to create a new user account.

GET /user/new
Response-body: {“form”: [
{“displayName”: {“type”: “string”, “comment”: “Your Name”}},
{“email”: {“type”: “string-email”, “comment”: “Email}},
{“realm”: {“value”: “39peers.net”, “comment”: “Account For”}},
{“password”: {“type”: “string-password”, “comment”: “Password”}},
{“credentials”: {“type”: “hash(email,realm,password)”}},
]} 

POST /user
Request-body: {“user”: {“displayName”: “Kundan Singh”,
“email”: “Kundan@example.net”,
“credentials”: “some-hash-of-password”}
Response-body: {“userId”: 42}

Login: The user login serves two purpose: inform the system about the current user availability and location, and authenticate and authorize to access the system. Existing protocols already define a login mechanism, e.g., SIP REGISTER, XMPP login, web login form. This system should separate the user availability and location requirement from authentication, so that login is used solely for authentication. As mentioned before, the server should facilitate third-party authentication, e.g., Google AuthSub, OpenID. Moreover the login should be allowed for different protocols.

POST /login/kundan@example.net          -- new login
Request-body:  {“clientId”: “some-random-id-426372”}
Response-body: {“url”: “/login/kundan@example.net/426372”, 
    “id”: 42, 
    “expires”: 600 }

PUT /login/kundan@example.net/426372    -- login session refresh

DELETE /login/kundan@example.net/426372 -- logout explicitly