<br><br><div class="gmail_quote">On Tue, Jun 26, 2012 at 9:00 PM, Michael Gapczynski <span dir="ltr"><<a href="mailto:mtgap@owncloud.com" target="_blank">mtgap@owncloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Tuesday, June 26, 2012 05:22:25 PM Georg Ehrke wrote:<br>
> Am 26.06.2012 um 17:17 schrieb Tom Needham:<br>
> > On 26 Jun 2012, at 16:06, Michael Gapczynski wrote:<br>
> >> We've briefly discussed the implementation of a REST API for ownCloud,<br>
> >> but<br>
> >> haven't formed any distinct plans for it. I believe we need to set<br>
> >> something in place now so developers can start using it and have some<br>
> >> nice<br>
> >> desktop and mobile integration for the next release. Besides desktop and<br>
> >> mobile clients, two Google Summer of Code students also require an API to<br>
> >> complete their projects.<br>
> >><br>
> >> What we need is a REST API that can handle user authentication and<br>
> >> ownCloud<br>
> >> instance to instance communication. My idea is that the API is defined by<br>
> >> the apps, in which they register actions and requests for the API to<br>
> >> listen to. The API will handle the authentication and pass on the<br>
> >> actions and requests back to the apps. To ensure a stable API, I believe<br>
> >> that actions and requests should be defined in appinfo/info.xml and<br>
> >> registered when the app is enabled.<br>
> >><br>
> >> An example of an action to revert a file back to a previous version:<br>
> >><br>
> >> files_versions/appinfo/info.xml:<br>
> >> <api><br>
> >><br>
> >>    <action><br>
> >><br>
> >>            <name>revert</name><br>
> >>            <parameter><br>
> >><br>
> >>                    <type>string</type><br>
> >>                    <name>file</name><br>
> >><br>
> >>            </parameter><br>
> >>            <parameter><br>
> >><br>
> >>                    <type>int</type><br>
> >>                    <name>revision</name><br>
> >><br>
> >>            </parameter><br>
> >>            <class>OCA_Versions</class><br>
> >>            <function>rollback</function><br>
> >><br>
> >>    </action><br>
> >><br>
> >> </api><br>
> >><br>
> >> The call to the action by a client using the API:<br>
> >> POST API/action/revert/<br>
> >> file:test.txt<br>
> >> revision:1340670981<br>
> ><br>
> > Should we include the app name in the url, for example, POST<br>
> > API/files_versions/action/revert. Otherwise, what happens if two apps<br>
> > register the same action? Or is it your intention that we do auth with<br>
> > OAuth and so the API will know what app is communicating with it?><br>
> >> An example of a request to retrieve the recent versions of a file:<br>
> >><br>
> >> files_versions/appinfo/info.xml:<br>
> >> <api><br>
> >><br>
> >>    <request><br>
> >><br>
> >>            <name>versions</name><br>
> >>            <parameter><br>
> >><br>
> >>                    <type>string</type><br>
> >>                    <name>file</name><br>
> >><br>
> >>            </parameter><br>
> >>            <class>OCA_Versions</class><br>
> >>            <function>getVersions</function><br>
> >><br>
> >>    </request><br>
> >><br>
> >> </api><br>
> >><br>
> >> The call to the request by a client using the API:<br>
> >> GET API/request/versions?file=test.txt<br>
> ><br>
> > Likewise for this URL obviously.<br>
> ><br>
> >> Returns XML or JSON<br>
><br>
> JSON might be the best solution. Just call json_decode and you got an easy<br>
> to handle array.<br>
> >> The API would also need to handle returning the proper http status codes<br>
> >> and converting the data into XML or JSON.<br>
> >><br>
> >> Our options are to create a REST API as part of remote.php (or a<br>
> >> different<br>
> >> location such as api.php) that can handle authentication of users or<br>
> >> extend<br>
> >> the Open Collaboration Services (OCS) API written by Frank. I'm thinking<br>
> >> that we shouldn't go through OCS in order to avoid confusion about what<br>
> >> the API actually is.<br>
> ><br>
> > Yes I'd say api.php would be most logical and least confusing.<br>
><br>
> I totally agree to a separated api.php.<br>
> What is about OAuth (2) for authentication?<br>
<br>
</div></div>I initially was thinking of using OAuth, but I'm not so sure anymore. WebDAV<br>
uses username, password and this API will not replace WebDAV. If we use OAuth<br>
for authentication the official mobile apps would need the username and<br>
password for WebDAV access and also go through OAuth for the API. This seems<br>
like too much work for me.<br>
<br>
I would prefer if official apps could just use username, password<br>
authentication and any 3rd party be forced to use OAuth. I'm not sure how to<br>
do this though without a 3rd party going through the same route as an official<br>
app.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>We can also do what Robin had suggested earlier - create a user backend where password will be oauth token. Then webdav clients can then use those tokens as passwords and do a normal http auth and get access to files.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
> >> Please share your thoughts.<br>
> >><br>
> >><br>
> >> Michael<br>
> >> _______________________________________________<br>
> >> Owncloud mailing list<br>
> >> <a href="mailto:Owncloud@kde.org">Owncloud@kde.org</a><br>
> >> <a href="https://mail.kde.org/mailman/listinfo/owncloud" target="_blank">https://mail.kde.org/mailman/listinfo/owncloud</a><br>
> ><br>
> > _______________________________________________<br>
> > Owncloud mailing list<br>
> > <a href="mailto:Owncloud@kde.org">Owncloud@kde.org</a><br>
> > <a href="https://mail.kde.org/mailman/listinfo/owncloud" target="_blank">https://mail.kde.org/mailman/listinfo/owncloud</a><br>
><br>
> _______________________________________________<br>
> Owncloud mailing list<br>
> <a href="mailto:Owncloud@kde.org">Owncloud@kde.org</a><br>
> <a href="https://mail.kde.org/mailman/listinfo/owncloud" target="_blank">https://mail.kde.org/mailman/listinfo/owncloud</a><br>
_______________________________________________<br>
Owncloud mailing list<br>
<a href="mailto:Owncloud@kde.org">Owncloud@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/owncloud" target="_blank">https://mail.kde.org/mailman/listinfo/owncloud</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<br>Deepak Mittal,<br>Twitter - @dpacmittal<br>