Re: State of Plone web api

On 17 Jan 2014, at 12:00 pm, Elizabeth Leddy <[email protected]> wrote:

> The most obvious question I have at this point is…. do people really need it that bad? I rarely set objects with an “api” in any framework, and if its needed I am usually wrapping like crazy to maintain certain behaviors and do extra… everything. GETting is obviously a win for ajax front ends but setting… I have my doubts. 
> 
> Please note I could be absolutely in a different boat on this - thats why I’m asking. Nothing troll-y intended.

My point exactly: most core developers have shell access to a Plone site so can write or install code to do whatever they want.
Imagine you don't have shell access or the ability to install new plugins. And you needed to upload a lot of content. What would you do?

My specific usecase is this code 
https://github.com/collective/transmogrify.ploneremote#transmogrify-ploneremote-remoteschemaupdater

It's designed as part of a toolchain to allow you to covert any existing website into any plone site WITHOUT having to install anything on that plone site.
Is that a reasonable objective? I think it's a reasonable request of a CMS that says its supports either open standards for exporting and importing content, or for web apis. We need to be in one of those camps if we are to call ourselves an enterprise CMS.

BTW, my latest branch is the only solution I've found so far to handle uploading where AT content uses schemaextender. That is to upload a pythonscript first and call that to do the updating, then remove it when you're done. Thats how hacky you have to get to do this kind of thing.

https://github.com/collective/transmogrify.ploneremote/compare/restrictedpython?expand=1


> 
> Liz
> —-
> Elizabeth Leddy
> [email protected]
> @eleddy
> 
> 
> 
> On Jan 16, 2014, 4:46:12 PM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
> 
> On 17 Jan 2014, at 3:26 am, Elizabeth Leddy <[email protected]> wrote: 
> 
> > 
> > On January 16, 2014 at 2:19:17 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 
> > The main issue with that was that it has no real security and required manage portal permissions. At the emerald sprint last year I expanded on it and added support for behaviors, included better accessors for dexterity attributes. The only reason I never finished merging it was that writing the test cases to check security was daunting, and like most things open source, my use case for it faded (and thus, my motivation). If someone wants to integrate it I can help: https://github.com/eleddy/puget.batshitcrazy . The main roadblock is getting the dexterity branch tested - you can rip anything you want for your own stuff from https://github.com/eleddy/plone.dexterity/compare. Really, thats the core code that would make api work easy to work with. The rest is slapping a pretty face on it. 
> 
> Unfortunately as far I can see this only handles serialising a single object which isn't the major problem. 
> 
> The example I have that doesn't work with the above api is setting fields. 
> 
> 
> We have in the past said things along the line of "everything in plone is a web api because of the zpublisher and xmlrpc support". I guess the point I'm trying to make is we seem to be writing methods and api in a variety of inconsistent styles all with python in mind, lots of which don,t translate to the web using our existing methods of calling them via the web. plone.api is yet another example written with python in mind and does not translate to the web. 
> 
> We should decide what is our overarching approach to web apis. 
> - Do we create a brand new api which is web centric and has REST bindings? e.g http://pythonhosted.org/wsapi4plone.core/ 
> - Do we replace XMLRPC with something else that works for a much greater number of our existing apis? e.g. allowing calling methods with named arguments such as json-rpc [1] 
> - or perhaps even an api where we can post arbitrary python expressions that get executed as restrictedpython and the results marshalled as json? 
> - eg /myfolder/@@pyapi?__code__=context.mypage.title%3Dvalue&value=blah. Anyone know if this could be made secure enough? 
> 
> I think that history tells us we need the solution here which needs the least possible maintenance since almost no core developer ever uses web apis. (since I imagine that we always assume we have shell access to a zope instance and can just do stuff in process). 
> 
> Note: json-rpc still wouldn't let us do direct assignment like dexterity expects to set fields. And it still wouldn't let us pass in objects as parameters like plone.api expects. But at least if someone is so unkind as to write a function like update(self, **kwargs) I would be able to call it remotely. 
> It also wouldn't handle calling views. 
> 
> [1] http://en.m.wikipedia.org/wiki/JSON-RPC 
> 
> > 
> > Liz 
> > 
> > 
> > 
> >> 
> >> 
> >> 
> >> 
> >> -- 
> >> Rok Garbas - http://www.garbas.si 
> >> 
> >> ------------------------------------------------------------------------------ 
> >> 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 
> >> _______________________________________________ 
> >> Plone-developers mailing list 
> >> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> >> https://lists.sourceforge.net/lists/listinfo/plone-developers 
> 


------------------------------------------------------------------------------
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