API Roadmap

From GNU MediaGoblin Wiki
Revision as of 18:41, 18 February 2012 by Joar (talk | contribs)
Jump to navigation Jump to search

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.

Use CORS to enable cross-domain AJAX request.

Authentication will be done using 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

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?