Both of these APIs are fully supported, but do not expose the full capabilities of Alfresco. Also, the development of new Web Services is expensive.
With this in mind, and looking to future features we'd like to support, it's time to take a look at how we provide a full-featured Remote API.
Providing a Remote API in itself is not a technical issue. However, it touches on many (current & future) aspects of Alfresco and so some thought-time is worth while. In parallel, the industry is focusing on standardising content management repository & services interfaces.
Moving forward, we would like to achieve the followings goals:
Stand-alone Repository Server (equivalent to database)
Detached Alfresco Web Client
Multiple Alfresco Web Clients against single Repository Server
Federated Repository Servers (distributed, not clustered)
Consistent API approach for server communication / application development
Make it easier to expose new Web Service APIs
Also, potentially touches on:
Federated Search (remote api is just one of many implementation approaches)
Public Query Language
Server Administration (run-time configuration)
Remote API is the definitive specification of public Repository capabilities
Remote API is specified in Java??
Provides all functions required by detached Web Client
Designed for remote access (really - latency, bandwidth)
Also accessible in-process
Support pluggable remoting protocols
Allow direct client access to remoting protocol
BPEL engine (SOAP), Ajax client/Browser (HTTP)
Support de-referencable (cross-repository) content/meta-data/node handles