Am 26.06.2012 um 17:17 schrieb Tom Needham:

> On 26 Jun 2012, at 16:06, Michael Gapczynski wrote:
> 
>> We've briefly discussed the implementation of a REST API for ownCloud, but 
>> haven't formed any distinct plans for it. I believe we need to set something 
>> in place now so developers can start using it and have some nice 
>> desktop and mobile integration for the next release. Besides desktop and 
>> mobile clients, two Google Summer of Code students also require an API to 
>> complete their projects.
>> 
>> What we need is a REST API that can handle user authentication and ownCloud 
>> instance to instance communication. My idea is that the API is defined by 
>> the 
>> apps, in which they register actions and requests for the API to listen to. 
>> The API will handle the authentication and pass on the actions and requests 
>> back to the apps. To ensure a stable API, I believe that actions and 
>> requests 
>> should be defined in appinfo/info.xml and registered when the app is 
>> enabled. 
>> 
>> An example of an action to revert a file back to a previous version:
>> 
>> files_versions/appinfo/info.xml:
>> <api>
>>      <action>
>>              <name>revert</name>
>>              <parameter>
>>                      <type>string</type>
>>                      <name>file</name>
>>              </parameter>
>>              <parameter>
>>                      <type>int</type>
>>                      <name>revision</name>
>>              </parameter>
>>              <class>OCA_Versions</class>
>>              <function>rollback</function>
>>      </action>
>> </api>
>> 
>> The call to the action by a client using the API:
>> POST API/action/revert/ 
>> file:test.txt
>> revision:1340670981
> 
> Should we include the app name in the url, for example, POST 
> API/files_versions/action/revert. Otherwise, what happens if two apps 
> register the same action? Or is it your intention that we do auth with OAuth 
> and so the API will know what app is communicating with it?
> 
>> 
>> 
>> An example of a request to retrieve the recent versions of a file:
>> 
>> files_versions/appinfo/info.xml:
>> <api>
>>      <request>
>>              <name>versions</name>
>>              <parameter>
>>                      <type>string</type>
>>                      <name>file</name>
>>              </parameter>
>>              <class>OCA_Versions</class>
>>              <function>getVersions</function>
>>      </request>
>> </api>
>> 
>> The call to the request by a client using the API:
>> GET API/request/versions?file=test.txt
> Likewise for this URL obviously.
>> 
>> Returns XML or JSON
>> 
JSON might be the best solution. Just call json_decode and you got an easy to 
handle array.
>> 
>> The API would also need to handle returning the proper http status codes and 
>> converting the data into XML or JSON.
>> 
>> Our options are to create a REST API as part of remote.php (or a different 
>> location such as api.php) that can handle authentication of users or extend 
>> the Open Collaboration Services (OCS) API written by Frank. I'm thinking 
>> that 
>> we shouldn't go through OCS in order to avoid confusion about what the API 
>> actually is. 
> Yes I'd say api.php would be most logical and least confusing.
I totally agree to a separated api.php.
What is about OAuth (2) for authentication?
>> 
>> Please share your thoughts.
>> 
>> 
>> Michael
>> _______________________________________________
>> Owncloud mailing list
>> Owncloud@kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
> 
> _______________________________________________
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

_______________________________________________
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Reply via email to