why does the RelationValue serializer not add the UID of the item? about plone.restapi

[mauritsvanrees]

This seems like a logical change to me. But I would be happy to read a different view point.

I have a PR #1586 that would fix this, and it is just one line. TODO: obviously some test fixes are needed. But if others do not like the approach, I would rather not spend the time.

Alternative is to explicitly request the UID as additional metadata. In a curl command:

curl -H "Accept: application/json" http://localhost:8080/Plone/page?metadata_fields=UID

[davisagli]

I think the philosophical justification for not including the UID in the REST API is that the REST API aims to always use an external URL as a resource identifier, rather than the UID which is internal.

But, URLs change when an item is moved or renamed, so I can see the benefit of being able to access the UID which is stable. I think we should include it.

Any objection, @tisto?

[tisto]

@fredvd @davisagli @mauritsvanrees I understand the value of having the UID for exportimport. Though, in general, I am wondering if we are comfortable exposing an internal database ID to anonymous users. I could imagine that this is something a security audit might complain about. What if we would just expose the UID attribute when the user has the manager role? This would solve the problem for exportimport and would not expose the UID for anonymous users.

[davisagli]

@tisto The thing is, I don't really consider it an internal database ID. Yes, we hide it from end users, but it also has a real purpose which is to be a stable UID that does not change when an item is moved around. That is not only useful inside Plone. If I want to put a stable reference to a Plone item in an external database, the UID would be the best choice.

In security audits at my last job the only concern about exposing internal ids was if they could be used to predict other ids. Completely random uuid4 ids like we use in Plone are not a security problem.

I would be fine with attaching it to a new "View UIDs" permission though. (Always protect actions with a permission, not a specific role. Then the policy for who gets the permission can be adjusted when necessary.)