[TYPO3-v4] REST API to CORE Functions

[Helmut Hummel]

Hi,

On 13.03.10 21:10, Francois Suter wrote:
> 
>> Anyway i'm interested which actions you have in mind getting from an
>> installation, i have some ideas like
> 
> Personally, I don't have a precise idea. Anything could be possible as
> far as I'm concerned. To give an example where I use my "remote_server",
> we receive data from a third-party application. This data is then
> inserted into some local TYPO3 tables, using my "external_import"
> extension, which uses TCEmain for storage. This means that this
> transaction can only be accomplished if there's a valid BE user.

Actually I implemented all CRUD actions for all TCA defined tables in
the extension typo3_webservice.

Currently the transfer layer is XMLRPC but this is very loosely bound to
actions themselves. It would not be possible to replace the Zend XMLRPC
Service classes e.g. with the Zend Soap classes in no time and therefore
have the same methods beeing accessible via SOAP.

Implementing REST is something different, but should also be possible.

> As Olivier mentioned it could really be anything. 

That's right. That's why I designed it to be modular. Registering a
class which provides e.g. the functionality Steffen mentioned would be
mostly a one-liner, then the methods of such a class would be
transparently be available through the webservice in a custom API namespace.

For the CRUD stuff I used the namespace "record.", so you can access the
functionality through calling record.get, record.list, record.create,
record.save and record.delete.

Having a class that implements the getTYPO3Version(),
getInstalledExtensions() ... could be in the namespace system:

system.getVersion ...

Adding functionality is really easy this way.

> The main issue is to
> have a secure way of handling such calls, i.e. authenticating and having
> the proper rights. 

I also chose the BE way for the CRUD implementation, using TCEmain for
all the actions.

For authentication I use a dedicated "login" api function where you
specify the BE user credentials and get back a session id for the BE
session, which you have to specify in each webservice call.

> The transaction itself could be further secured by
> using public/private key pairs. 

Since I encapsulated the login into an authentication object, it would
also be possible to authorise over other methods like public/private key
pairs.
What stays is the necessity to transmit the session id for each request.
But especially when thinking about REST, I think there's no way around
such a sessionid, token ore appid for such calls. It's also the same for
a normal BE session, where the session id is transmitted by a Cookie.

> The "caretaker" extension does this, but
> I haven't looked in details how it's done. It could be another source of
> inspiration.

Is anyone of you interested in attending a workshop on this topic at the
T3DD10?
We could gather our ideas and as a result we could probably have a
concept how such a webservice should be structured and how an API could
look like.

Regards Helmut