Re: State of Plone web api

On Thu, Jan 16, 2014 at 2:11 AM, Rok Garbas <[email protected]> wrote:
> i'm not sure what the state of the work is. but there was an idea that
> plone.api could be used and expose most of its calls also via json
>
> https://github.com/xiru/plone.api.json

I have to wonder if (only having) a procedural API on top of a
placeful, resource-centric system defeats all the "good parts" of what
object publishing is really about.  REST (or some REST-like subset
leveraging traversal) seems more ideologically aligned with what we
ought to have.  It's all about the resources, not the controllers that
so mundane things to them.  Exposing plone.api (securely, if possible,
perhaps in part) over HTTP ought to be seen as a good start, though.

My wish-list if I could have everything I want in remote APIs:

* RPC: set/get property (like WebDAV) on a remote object.

* RPC: list properties

* DAV GET/PUT -- serialized objects: JSON or RFC822 representation,
with as much of a round-trip as possible.

* Vary for DAV: opportunity to vary the output of manage_FTPget() on
request predicates (e.g. some user-agent expects XML, integrator
should be able to write adapter to do that).

* Procedural: plone.api functions for managing global stuff (like adding users).

* Resource traversal: some site/navigation root traversal adapter /
entry-point URL such that all subsequent traversals are in JSON/REST.

* Complete state: for a content item, ability to access content
fields, workflow history, ability to access compound wrapper for
file+metadata.

* Compound document: ability to make a folder serialize to a zip file
or ODF or some other compound document composed from its contents
based on some adapter, if present.

* Authentication: basic auth, maybe OAuth2.

* Nice adapters for media files: for example, ability to specify (by
behavior?) that a JPG photo has IPTC, Exif, and XMP written in the
JFIF stream for metadata kept in Plone, such that common fields
round-trip from just the binary download (esp. for External editor).

* External editor: would be nice to keep this working, maintained for
the niches it works well in.

* Search: nice API for searching catalog.

* Addressable: get anything over API by addressing with a UUID or a path.

* Discovery: Nice APIs for collections, such that collections created
for feeds, new content, etc are easy to script against.

* CMIS server (minus the query bloat): for basic object
retrieval/syndication, why the heck not?  Maybe just something on top
of the DAV implementations that already mostly work.

Sean

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk