Resource REST

[Daniel Leech]

Just to clarify my position on the REST support on the Resource stack.

Resources are based on Puli resources. They are abstract representations
of an underlying payload (document / entity).

Resource provide common abstraction which can be used for resource
location, e.g. for templates, routes, etc. Resource trees can also be
used to provide a standard back-end for tree browsers.

It is based on Puli, which so far seems to be working OK - we benefit
from free support Filesystem and Composite repositories as well as
progress made upstream.

Sylius also has a Resource bundle. The concept is slightly different:

- Provides an abstract query builder implementation.
- Form builders
- REST API
- Routing
- Integration with the Sylis GridBundle (for rendering and managing "admin lists")

What it does not provide is a tree structure - it is not about resource
location, but resource management - it is an admin backend for
resources.

I don't see any specific reason why we should NOT ultimately have this
sort of functionality in the CMF - it would actually be a perfect use
case for the organization - but it would envolve quite a bit of work
(for which we do not have resources) and would be competing directly
with Sylius which already has quite a good and nicely decoupled bundle.

A pure CMF "resource backend" would have it's advantages but at the
moment I don't think its worth the effort when there is already a
relatively mature solution available which meets most of our
requirements.

Of course its not my decision, just my thoughts.

Cheers,

Dan

[Lukas Kahwe Smith]

So to summarize:
- For now at least point people towards the Sylius solution.
- Figure out a way to add tree handling
- Once Puli is stable, see about how to proceed

?

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Daniel Leech]

The only thing I think we need to sort out is how we add the
Sylius/Sonata meta-information (URLs for REST/HTML endpoints).

https://github.com/symfony-cmf/resource/issues/18

Tree handling is already handled by the Resource stack - we just
delegate creation and edition to Sylius/Sonata.

> - Once Puli is stable, see about how to proceed

I don't think Puli being stable will necessarily affect how we proceed -
the only notable thing which is missing is the ability to move
resources:

https://github.com/puli/issues/issues/42

We also need the ability to reorder, but I think that will have to be
a feature of the resource component rather than Puli.

[GMX - Maximilian Berghoff]

Hey Dan,

so our positions arn't that far as our discussion in our PR's :-) You
are simply concerned about the work and our resources, isn't it?

I thought "why having a resources-rest-bundle and just have GET only" I
mean REST isn't complete by fullfill all CRUD methods, but i really love
the idea of resources as they a that near to the way REST thinks
resources (location, state,..), but REST without any state transfer does
not sound complete. You proposed to support the following functions on a
resource:
- move
- delete
- rename
- get
for the beginning. And yea i can live with that, as it is the beginning
of a state transfer. Move and Rename would change the path and "local
name" of a resource and the underlying payload. The only thing we should
do is to speak about it, means to explain why a REST api on resources
wouldn't change the payload, maybe it would just propose other urls to
do so.
But to do the minimal we should open a minimal door in the
RepositoryInterface of the resource component, means completely implment
the EditInterface. What to use and how to use it would be a discussion
when using that door from the resource-rest-bundle.

To complete the REST picture i would propose to have a API, maybe by the
help of SyliusRestBundle (+ for Deserialisation, QueryBuilder), to work
on content documents. Maybe by example in ContentBundle only. David and
I are on a good way to support method aware routing for our dynamic
router. So i do not think the use the static router of Sylius (maybe in
a chain). So i would propose a enhancer or equal to fill route
parameters with the values Sylius would need them.
Why content-bundle? Yea i really love the idea of the api endpoint based
on the routes of a content document. That would make frontend-editing
more easy as the routing is easy and the client application can think
the way a user would go through the HTML frontend.

greets max

[Daniel Leech]

That's what I currently propose.

> But to do the minimal we should open a minimal door in the
> RepositoryInterface of the resource component, means completely implment
> the EditInterface. What to use and how to use it would be a discussion
> when using that door from the resource-rest-bundle.

We need to implement the EditableRepository interface. But I am pretty
sure this doesn't open the door to editing the payload itself, but
resource stack would be able to tell you *how* to do that.

>
> To complete the REST picture i would propose to have a API, maybe by the
> help of SyliusRestBundle (+ for Deserialisation, QueryBuilder), to work
> on content documents. Maybe by example in ContentBundle only. David and
> I are on a good way to support method aware routing for our dynamic
> router. So i do not think the use the static router of Sylius (maybe in
> a chain). So i would propose a enhancer or equal to fill route
> parameters with the values Sylius would need them.
> Why content-bundle? Yea i really love the idea of the api endpoint based
> on the routes of a content document. That would make frontend-editing
> more easy as the routing is easy and the client application can think
> the way a user would go through the HTML frontend.

With the multiple method support you could probably easily forward
requests to the Sylius ResourceController (or similar), with minimal
code.

>
> greets max