Support REST, not just GET

[wouterj]

The ResourceRestBundle is now just a ResourceGetBundle. In order for it to be usable with the TreeBrowserBundle, it has to support move, write and delete actions.

[dantleech]

+1. I think we need:

• Resource renaming
• Resource moving
• Resource deletion

Moving is the trickiest, as you cannot move a PHPCR resource to a Doctrine ORM branch. Or move Doctrine ORM entities to ORM branches of different types. PHPCR resources may have child restrictions etc.

So we need to add information about what are valid and invalid parents for each node/type, if the node can be renamed, deleted, etc.

Or maybe we could just delegate these operations to the layer below the resource system, but then the APIs would not be gauranteed to be consistent.

Not sure how much of this could be implemented in the Puli API /cc @webmozart

[dantleech]

• Delete is not necessary I think .. this can and should be handled by Sonata via the delete _link. wdyt?
• Moving should be handled by the resource repository, see linked issue
• What do you mean by "write" ?

[dbu]

what about create / update? also not the job of this bundle? i would assume FOSRestBundle handles most of that already...

[dantleech]

yeah, creating a new resource would involve creating a new instance of the thing the resource represents, which is surely out of the scope of this bundle. (at the limit we could imagine some super abstract CRUD system for resources with mapping and everything, but well, thats crazy for now).

Users can map their own REST endpoints using the HateOasBundle, and the serializer will pick that up here.

[dantleech]

I imagine the we would depend on a specific key for the URL being present in the response, e.g. _links: { create: "/path/to/create", edit: "/path/to/edit/123" }. We would make the keys configurable in the tree browser JS.

[ElectricMaxxx]

for create i would suggest requests like `POST /api/repo_phpcr/cms/content/collection" or "PUT /api/repo_phpcr/cms/content/collection/name" (explicit). And i think we need some information about the resource to create, maybe an own header equal to the content-type?

[dbu]

the CreateBundle solves this problem with json-ld requests that specify what to create. as far as i remember, we however leak information to the frontend as the exact document class is specified.

editing is a lot easier, as you can just load the document in question and see what is there.

the paths should be the same as for GET but with different methods.

[ElectricMaxxx]

I would call the links described by @dantleech HATEOAS :-)

And @dbu no, the paths can't be the same for all methods (except we stroke the word REST from this bundle). The create path should be on a kind of a collection of resources, while edit/delete goes on the resource itself. You can, if you know the correct position of the resource, create by a PUT request.

That spoken, even a collection should be a resource that i can fetch by that bundle. doing that i would get a create route too - as a kind of "add buttton". In general we should provide schemas of a document's fields in a nice format, maybe not RAML. I recognized the ALPS specification some weeks ago and think that can be the right tool, cause customers of the api will get a detailed information for each format AAANND can create Forms out of the information => create-bundle/frontendenditing. So i created #29 for that.

[dbu]

you are correct max, we can't have the same url for creating and editing.

i think one philosophy confusion we have with this topic is that PHPCR is a tree structured database, while REST with its resource orientation is essentially thinking in relational database terms. the question for us is if we want to talk to "class" oriented paths to read data in a relational model and specify the paths in the repository somehow, or if we want to use paths that reflect the PHPCR tree structure and need to specify the classes of the documents somehow.

create bundle is doing more of a RPC style thing, sending both class and repository path to a fixed URL. what we are currently adding to the cmf routing would help with a PHPCR oriented model. ResourceRestBundle probably takes the relational model.

[ElectricMaxxx]

There is also an third way of reaching the content: on an api defined by their routes (content-bundle).
Here we reach each node in the tree by its path for two repositories: phpcr and phpcr_odm.