API Roadmap

Sessions

2012-02-18: Hacking session

Try to determine what kind of authentication we could provide for the descibed scenario.

According to http://webreflection.blogspot.com/2008/06/ajax-or-javascript-subdomain-requestes.html it is possible to access a subdomain from another parent domain/subdomain sharing the same parent domain. not feasible.

Results

Use CORS to enable cross-domain AJAX request since all existing cross-domain solutions use an iframe.

Authentication will be supported by OAuth.

Network layout

OS is a web application that has the intention to store mediafiles in the MGS (MediaGoblin server). OC is a client visiting the OS web application.

Submission - proposal

OC visits OS with the intention to submit an image
                    |
                    V
OC authenticates to MGS via JavaScript OAuth
    (This is where I have no idea what 
           I'm doing as of now)
                    |
                    V
OC submits a POST to MGS, not breaking the same origin
    policy by placing MGS on a subdomain to OS.
The POST contains a CALLBACK URL, which MGS will issue
 when doen processing the media submitted in the POST

Resources

Links

• OAuth code examples - http://oauth.net/code/
• REST API

Tasks

1. Define structure of REST API
2. Implement the REST API
3. Implement CORS
4. Implement OAuth

IRC source

13/12:03.55 < tryggvib> joar: I've been thinking about what work you could do 
                        and after looking at the current version of nyergler's 
                        API on the wiki I have a good idea
13/12:05.09 < tryggvib> 1. Design the backbone structure (structure gmg around 
                        the json accepts (I'd guess you want to keep the api 
                        views seperate from the 'normal' http views
13/12:07.11 < tryggvib> 2. Implement the authorization code (OAuth 2.0, even 
                        though that means we'd show the key on our side (with 
                        the js oauth implementation)
13/12:07.47 < tryggvib> (with 2. I mean the OAuth gmg part and this could be 
                        split into two parts - 2a. read and familiarize 
                        yourself with OAuth, 2b. implement OAuth)
13/12:08.13 < tryggvib> 3. implement the /u/<username>/gallery/ endpoint
13/12:08.26 < tryggvib> 4. implement the /u/<username>/m/<slug> endpoint
13/12:09.40 < tryggvib> so the big uncertainty would be the OAuth 
                        implementation I think
13/12:10.54 < tryggvib> first of all I don't know if we've reached any 
                        agreement about using it and secondly since we have to 
                        familiarize ourselves with it the implementation time 
                        estimate is hard
13/12:13.05 < tryggvib> Depending on the gmg code I also don't know how big 1. 
                        will be, but I guess it should not be all to difficult
13/12:18.25 < tryggvib> Even though this is directed to joar, everybody else 
                        can chip in some thoughts (that's why I'm posting this 
                        here)
13/12:20.45 < joar> tryggvib: perhaps it would be a good idea to make a 
                    proof-of-concept for the authorization.
13/12:21.10 < tryggvib> yes
13/12:22.21 < tryggvib> there are a few things I'd like to add to items 3. and 
                        4. though
13/12:23.04 < tryggvib> for the POST in item 3. we need the optional callback 
                        URL which get called when the processing of the media 
                        file is done
13/12:23.54 < joar> the POST action is actually on a different view set, you're 
                    thinking of submit.views, I believe.
13/12:24.11 < tryggvib> and for the GET in item 4. I would also want to get a 
                        thumbnail and the cc info
13/12:24.59 < joar> tryggvib: Can I write this down in the wiki?