Wrong @id when creating a folder

[jone]

I created a folder on a fresh Plone 4.3.7 installation.
REQUEST:

POST /Plone HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: Basic YWRtaW46YWRtaW4=
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: 63309be4-3a64-8ca5-da79-773bae296644

{
    "@type": "Folder",
    "title": "A Folder"
}

RESPONSE:

{
    "@id": "http://localhost:8080/Plone",
    "@type": "Folder",
    "UID": "44699c543d49471dbc0d03ca017f099c",
    "allowDiscussion": false,
    "constrainTypesMode": 0,
    "contributors": [],
    "creation_date": "2016-12-28T15:24:30+01:00",
    "creators": [
        "admin"
    ],
    "description": {
        "content-type": "text/plain",
        "data": ""
    },
    "effectiveDate": null,
    "excludeFromNav": false,
    "expirationDate": null,
    "id": "a-folder",
    "immediatelyAddableTypes": [
        "Document",
        "Event",
        "File",
        "Folder",
        "Image",
        "Link",
        "News Item",
        "Collection"
    ],
    "items": [],
    "items_total": 0,
    "language": "de",
    "lastModifier": "admin",
    "locallyAllowedTypes": [
        "Document",
        "Event",
        "File",
        "Folder",
        "Image",
        "Link",
        "News Item",
        "Collection"
    ],
    "location": "",
    "modification_date": "2016-12-28T15:24:30+01:00",
    "nextPreviousEnabled": false,
    "parent": {
        "@id": "http://localhost:8080/Plone",
        "@type": "Plone Site",
        "description": "",
        "title": "Website"
    },
    "relatedItems": [],
    "review_state": "private",
    "rights": {
        "content-type": "text/html",
        "data": ""
    },
    "subject": [],
    "title": "A Folder"
}

PROBLEM:
@id is http://localhost:8080/Plone, but I expected http://localhost:8080/Plone/a-folder.

Be aware that it works correctly with Document, but it does not with Folder.

[lukasgraf]

@jone nice catch, I was able to reproduce this.

Looks like this is an unintended interaction of batching and the fact that in POST responses the content now gets serialized back to the client (#144):

On a POST, the serializer for the content object that just got created will be looked up and called. For folderish objects, the serializer will delegate building of items, items_total and the @id to a HypermediaBatch.

The HypermediaBatch's logic for constructing its canonical_url is admittedly pretty naive: It basically just takes it from request['ACTUAL_URL'], which worked just fine for GET, where the request hits the container in question. But for POST, the target object is the container where the new folder will be created, hence the incorrect canonical_url.

This raises a couple questions:

• Does it make sense to set result['@id'] to batch.canonical_url in the folder serializer? (I might just have copied that over without thinking too much about it)
• Do we even want to delegate this stuff to HypermediaBatch when serializing in a POST? Newly created containers will be empty by definition, at least until we've got some sort of bulk-creation API