plone / plone.restapi

RESTful API for Plone.
http://plonerestapi.readthedocs.org/
86 stars 77 forks source link

Building extensions/plugins? #504

Open zopyx opened 6 years ago

zopyx commented 6 years ago

Discussion: what is the best way to provide extensions or plugins?

For migration purposes I need to build at least the following additional remote methods:

I am aware that plone.restapi is primarily designed to serve as endpoint for headless applications in the first place...I am not sure if the functionality above belongs into the plone.restapi core or in some add-on package or some plone.restapi extension...what is the best approach for adding such custom functions on top of the plone.restapi?

tisto commented 6 years ago

create/recreate a new Plone site with a given list of extension profile (kind of provisioning API)

I'd love to have that feature! A long time ago I build upc.remotecontrol (https://pypi.python.org/pypi/upc.remotecontrol/1.0a1) which did something similar via XMLRPC. A possible problem might be that we need a REST endpoint on Zope-level. So this could either be an add-on product or on plone.restapi core.

support for setting the default page of a folder

That should definitely go into plone.restapi core. We are currently experimenting with folderish content objects but there are still issues that need to be solved. We also have to support the status-quo here.

methods related to portlet configuration

I created a ticket for that already. For our project we went with a lightweight tiles solution so far, so this was not needed in the end. This could and should go into plone.restapi core.

I am more than happy to help to bring those solutions into plone.restapi core. The upcoming Beethoven sprint in Bonn might also be a good opportunity for this. We would love to have you there if you want to work on those issues! :)

zopyx commented 6 years ago

A provisioning endpoint for creating a Plone site would have to be a standard browser view because plone.rest does not work outside a Plone instance.

tisto commented 6 years ago

Using a browser view means we have to do a GET request to create/update/delete a resource (e.g. the Plone site). This violates the HTTP standard and REST best practices that we use in plone.restapi. So whatever we would do there would significantly differ from the other endpoints which would lead to a bad API "user experience".

The right way to do this would be to enhance plone.rest to support REST calls on Zope level, which should be possible. plone.rest has no Plone deps (https://github.com/plone/plone.rest/blob/master/setup.py#L53).

Though, I understand why this might be too much work just to "do it right" if you can accomplish the same with far less work (a browser view). Though, if we want this to be in core we have to follow our best practices and REST principles IMHO...

zopyx commented 6 years ago

You can write a browser and and perform a check for the REQUEST_METHOD...bu I will look into the plone.rest implementation why it does not work as thought with the Zope root.

tisto commented 6 years ago

@zopyx awesome!

zopyx commented 6 years ago

The problem with plone.rest and the Zope root object is possibly the default layer for plone.rest ZCML declarations (IDefaultBrowserLayer) which is not set on the Zope root object. Perhaps it makes sense definiing a customer layer only for this purpose and attaching it to the root object.

tisto commented 6 years ago

I am ok with a custom solution just for the Zope root if the API endpoint behaves in the same way the other endpoints work.

tisto commented 6 years ago

@zopyx did you ever looked into that? Anything that you could share to get it into plone.restapi core?

zopyx commented 6 years ago

Not really useful. I maintain my own (small) provisioning API with a few methods but they are not integrated with plone.restapi. The related code is always only a few lines...but here is the a gist with the related file: https://gist.github.com/zopyx/fc4c57c6fdbf04c5f1f275c7483187f2