Re: [GMG-Devel] API proposal

[Christopher Allan Webber]

By the way, I had a chat with the OpenPhoto lead developer today on the
phone, mainly about ostatus and etc, but it was brought up afterwards
that one thing they *do* have already is an API:

<jmathai> just had a thought actually
<jmathai> so both of our projects are decentralized. we already have an
          api…i'm not sure how well it applies to what you're doing but if
          there's interoperability there then the (mobile) clients for
          openphoto could also work with media goblin
<jmathai> just something to chew on...
<paroneayea> jmathai: do you have documentation on your API?
[...]
<jmathai> 
https://github.com/openphoto/frontend/blob/master/documentation/api/Api.markdown
<jmathai> currently using oauth 1.0a

We don't have to borrow their API, but might help to consider.

 - cwebb


Nathan Yergler <address@hidden> writes:

> Exact same URLs, using only HTTP to dispatch requests. I don't see any
> reason to make it a different WSGI app, and something in me says "the
> resource is the resource is the resource" -- whether I want HTML,
> JSON, or XML back, there should be one URL to get that resource
> information.
>
> NRY
>
> 2011/11/13 Christopher Allan Webber <address@hidden>:
>> Great!  Thanks for this work, Nathan.
>>
>> Putting yours/Tryggi's goals aside and commenting directly on what you've 
>> written, I
>> have just one question in my somewhat sleepy state: do you anticipate
>> the API being mounted as a separate wsgi app, in the same app but at a
>> particular URL (like /api/), or run under all on the exact same URLs but
>> using the request headers to indicate that it's acessing it via the API?
>>
>> Option #2 is probably easiest for now?  Curious what you think though.
>>
>> Thanks,
>>  - Chris
>>
>>
>> Nathan Yergler <address@hidden> writes:
>>
>>> So I've been thinking about this over the past few days, and today
>>> managed to get some thoughts down in the wiki.
>>>
>>> http://wiki.mediagoblin.org/REST_API
>>>
>>> My goals may be somewhat different than Tryggvi's; my intention is to
>>> create an API that allows non-browser clients to upload and retrieve
>>> media from GMG instances, leveraging straight-up HTTP as much as
>>> possible. The document is intentionally vague: I suspect that there
>>> are lots of things we don't know yet.
>>>
>>> I have thoughts about how to start development of this (and I think
>>> starting to build it will be a great test of how it works; if I'm
>>> 'right' it should feel easy :) ). But at this point I'd like to get
>>> some feedback. Does it pass the smell test? Does it meet basic use
>>> cases? Are there things that seem totally whacky to you?
>>>
>>> Thanks for your patience, looking forward to feedback.
>>>
>>> Nathan
>>>
>>> 2011/11/11 Tryggvi Björgvinsson <address@hidden>:
>>>> On 11/07/2011 12:04 AM, Tryggvi Björgvinsson wrote:
>>>>>
>>>>> As discussed at the IRC meeting yesterday I promised to write up an API to
>>>>> use as a springboard for nyergler to improve and work from. I wrote the
>>>>> proposal (for a very specific scenario) on the wiki:
>>>>>
>>>>> http://wiki.mediagoblin.org/API
>>>>>
>>>>> As you can see this is a really specific API which wasn't created with
>>>>> MediaGoblin in mind and only for submission of files but could be useful 
>>>>> to
>>>>> launch the API discussion and work.
>>>>
>>>> After a discussion yesterday on #mediagoblin with paroneayea and Elrond, I
>>>> found out that MediaGoblin will start to process files immediately after
>>>> upload no matter what. This makes the claims/expiration idea useless so we
>>>> came up with a better approach to API which isn't as use case specific,
>>>> easier to implement and overall just cleaner. Instead of claiming files 
>>>> with
>>>> callback URL/webhooks. The callback is provided as an optional variable on
>>>> upload (when files are uploaded, the application uploading can send a URL
>>>> for GMG to POST to when processing is finished).
>>>>
>>>> I have modified the wiki page accordingly and split the API up into two
>>>> different APIs. One for submission, the other for Metadata. So we need to
>>>> provide the upload+webhook POST option and then implement the callback JSON
>>>> API.
>>>>
>>>> If the uploading application (the US) wants to add metadata to the file
>>>> (such as a Creative Commons license) that should be possible through a
>>>> different API.
>>>>
>>>> Hope this clears things up and avoids hurting in Nathan Yergler's brain 
>>>> when
>>>> he tries to understand what I am trying to explain.
>>>>
>>>> /Tryggvi
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> address@hidden
>>>> http://lists.mediagoblin.org/listinfo/devel
>>>>
>>> _______________________________________________
>>> devel mailing list
>>> address@hidden
>>> http://lists.mediagoblin.org/listinfo/devel
>>