API Roadmap

= Roadmap =
 * 1) API_Roadmap
 * 2) API_Roadmap
 * 3) Implement the REST API
 * 4) * Views
 * 5) *** Accept webhook argument
 * 6) *** Offer alternative output format
 * 7) *** Offer alternative output format
 * 8) *** Offer alternative output format
 * 9) Add webhook callback to Processing
 * 10) CORS
 * 11) * CORS-enable views
 * 12) **  wrapper for views
 * 13) OAuth
 * 14) * OAuth research
 * 15) * OAuth views
 * 16) ** Request
 * 17) ** Access
 * 18) ** Authorization
 * 19) ** Callback
 * 20) ** Resource
 * 1) ** Authorization
 * 2) ** Callback
 * 3) ** Resource

Discussions with the community
Specify details of API implementation.


 * Where should we mount the API?
 * How should we determine what output will be sent back to the user?

REST_API might contain some usable input on this.

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
 * &hellip;

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

= Content from the planning phase =

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

Links

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

IRC source
13/12:03.55 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 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 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 (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 3. implement the /u/ /gallery/ endpoint 13/12:08.26 4. implement the /u/ /m/ endpoint 13/12:09.40 so the big uncertainty would be the OAuth                        implementation I think 13/12:10.54 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 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 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 tryggvib: perhaps it would be a good idea to make a                    proof-of-concept for the authorization. 13/12:21.10 yes 13/12:22.21 there are a few things I'd like to add to items 3. and                         4. though 13/12:23.04 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 the POST action is actually on a different view set, you're                     thinking of submit.views, I believe. 13/12:24.11 and for the GET in item 4. I would also want to get a                         thumbnail and the cc info 13/12:24.59 tryggvib: Can I write this down in the wiki?