[TYPO3-dev] TYPO3 Webservices API // REST for TYPO3

[Nicolas Forgerit]

Hey guys,

i'm working on implementing a Webservices API (WSAPI) and subsequently
a RESTful API for TYPO3v6. [0]

I'm currently somewhat stuck thinking about the best way of
implementing the main entrance point to a TYPO3 instance for such a
WSAPI. In the past, seeing the rather "hacky" bootstrapping code of
TYPO3 i was confident to introduce such a functionality through a
distinct path: Path_site/api/index.php. (See Pros/Cons list below.)
Now seeing the bootstrap refactoring in v6-alpha2 i'm not as conviced
as before. Thus, i'm asking for some thoughts on that. Did the
bootstrapping-refactor-people think about something like a WSAPI or
even REST? How do TYPO3_REQUESTTYPE_(AJAX|CLI) fit into the game? Imho
they are both some specific API call and should be handled by a
specialized script which is reusing several Bootstrap.php code parts.

I'd be glad about some input on that and i'm looking forward to your
thoughts and ideas.

Ciao Nico

---

Advantages of having a distinct API entrance to TYPO3:
- Webservice (API in general) is neither FE nor BE. It's as well both
and neither. Thus "mapping" WSAPI to index.php or typo3/index.php
seems a bit of a wrong pragmatism to me.
- WS should be fast. I'd like to avoid preliminary loading of stuff
that is not needed in every case. (DB, Autoload, ...)
- introducing the new entry point api/index.php would set up a
convention of having api calls: Requests to typo3-cme.org/api/...
ever belong to WSAPI. Introducing such a convention could help
avoiding issues with URL-prettifying extensions
- the folder /api can easily be mapped to a subdomain through a vhost
leading to something like api.typo3-acme.org/...
- i think, each use case can be mapped to either FE, BE or API - cli
heavily corresponding to the last one and not to
- imho much better scalable in case of WSAPI being widely accepted and
subsequently pimped a lot ("we need acl's/api-user configuration/...")
as this can then be handled separately without any further
dependencies.

Disadvantages of having a distinct API entrance to TYPO3:
- too many entrance points could lead to a too complex architecture
and code duplication. However, the new bootstrapping capabilities
being introduced in v6 help reusing orthogonal functionalities.
- could be too hard to load core capabilities after the WSAPI-engine
was called, e.g. for extension developers to reuse their existing
Extbase code


[0] For the broad picture: I think, a RESTful API for TYPO3 decomposes
into a general WSAPI component [i.e. stuff that needs to be in Core]
and a REST component [i.e. stuff that may go into a
(system-)extension]. While the former would collect all routes defined
in e.g. EXT:foo/ext_api.php, caches and executes them depending on the
API-request the latter would provide some general TYPO3
functionalities through a RESTful interface (for the start: pages,
content, users, groups) as well as some special API for extension
developers for providing a RESTful (good lord, i'm starting to hate
the pun) interface á la Slim framework [1] in combination with Fluid
for composing resource representations. I've had a look into some
JAX-RS code and i think that this approach (i.e. describing RESTful
interfaces via Annotations) does not really fit into our problem
domain [2].

[1]
You may have seen this in several PHP micro-frameworks like Silex,
Slim, Laravel et al. Mapping routes to functions is done in-place.
Pretty handy for small appliances, pretty confusing in big
applications. However, i think WSAPI would pretty much fit this
approach since the number an extension's additional RESTful resources
would be within 1-10, rarely more.
http://www.slimframework.com/documentation/stable#routing

[2]
Basically, JAX-RS describes RESTful interfaces through Annotations on
POPO's. Whereas this may come in handy in big Java enterprise
applications, i don't think this fits the purpose of a sole extension
developer willing to provide a handful of additional resources for
accessing his extension's data.
http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services