API Roadmap

Roadmap

1. Specify details of the REST API
2. API_Roadmap#Investigating_already_existing_protocols
3. Implement the REST API
   • Views
     • /submit/
       • Accept webhook argument
       • Offer alternative output format
     • /u/{user}/m/{media}
       • Offer alternative output format
     • /u/{user}/gallery/
       • Offer alternative output format
4. Add webhook callback to Processing
5. CORS
   • CORS-enable views
     • CORSEnabled wrapper for views
6. OAuth
   • OAuth research
   • OAuth views[1]
     • Request
     • Access
     • Authorization
     • Callback
     • Resource

Investigating already existing protocols

Before reinventing the wheel, we should analyze existing wheels. That means, existing protocols should be evaluated, whether they fit the needs. Of course only a certain subset of "old wheels" can be looked at, but the most important ones shouldn't be left out. Using an existing protocol could also save work. At least on the client side, because the clients usualy already exist. Existing clients could also greatly help in developing the server side (easy testing!). The results of this evaluation should be documented so that there is an easy place to point people at who ask "Why didn't you use Y for your main protocol, it's great!".

Protocols that come to mind, and should possibly be evaluated:

• flickr api
• gallery2 api
• …

Of course any of those "old wheels" can later be implemented as a plugin and be enabled by users.

Content from the planning phase

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. This did not seem like a good idea after all. It has been decided to use CORS for cross-domain requests.

Results

• CORS to enable cross-domain AJAX requests.
• OAuth for authentication

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

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?