Sure, the server can handle autoincrementing the version for minor revs, but how would the client indicate it intends for the revision to be a major version
bump? 1.0.15 -> 1.7 for example.
Hmm.
1.
POST /policies/{policyid}/ -> version field in body must match the current tip, and server autoincrements to produce new version (1.0.15 -> 1.0.16)
2.
POST /policies/{policyid}/{version} -> creates a new “branch” of the document with the indicated version (1.7). The base version from which the new
version is branched can be expressed in the version string in the policy in the body of the request.
That might suffice, but this requires the client to know how to compose the vendor’s URL pattern. The REST API profile thus far has avoided specifying any
URL patterns.
Other ideas?
-Danny
Danny Thorpe
Product Architect |
|
Quest Software -
Now including the people and products of BiTKOO |
www.quest.com
From: Craig R Forster [mailto:cforster@us.ibm.com]
Sent: Tuesday, May 22, 2012 12:32 PM
To: Danny Thorpe
Cc: remon.sinnema@emc.com; xacml@lists.oasis-open.org
Subject: Re: [xacml] REST Profile wd04
>> Suggestion: The client MUST set the Policy/Set version field to the version string desired for the new document to be created by the POST.
>> If the unique key combination of policy ID + version string already exists in the repository, the response MUST fail with (409 Conflict).
Shouldn't the server control the version?
I'd imagine the "RESTful" way to do this would to have the client POST to the base URL, then have the server generate a new version and return the URL of this new version in the Location HTTP header.
Regards,
Craig
-------
craig forster | technical lead, tivoli security policy manager
cforster@us.ibm.com
-------
Danny
Thorpe ---05/22/2012 02:25:42 PM---Section 1.5 - Can we add a use case for PDP <- PAP? A PDP may use the REST API to fetch policies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Section 1.5 - Can we add a use case for PDP <- PAP? A PDP may use the REST API to fetch policies for evaluation.
----
Section 2.2.3.2 Policy or PolicySet
There’s no indication or guidance about how the version of the document being posted is computed or identified. Is this a minor revision, or is this bumping the revision from 1.0.0.123 to 1.5?
Suggestion: The client MUST set the Policy/Set version field to the version string desired for the new document to be created by the POST. If the unique key combination of policy ID + version string already exists in the repository, the response MUST fail with
(409 Conflict).
-------
Suggestion: An observation somewhere that GET/POST/DELETE may not be symmetric for all policy resources. Implementations may expose individual policies for reading via GET but not support direct editing of that policy because that policy is a child element
contained in a parent policyset. The parent policyset document can be identified by a link with an “enclosure” link relation. The linked parent document should be the topmost parent or “root” policyset document (not an intermediate parent which is itself a
child of the root policyset).
Perhaps the phrasing should be turned the other way around: Because XACML policy/set references allow referencing external policy/sets without regard to their containment, REST API implementations SHOULD make child policy/sets accessible via GET even if such
resources are not editable independently of their parent documents. The parent policyset document can be identified in the child policy ATOM element by a link with an “enclosure” link relation. The linked parent document should be the topmost parent or “root”
policyset document (not an intermediate parent which is itself a child of the root policyset).
I’m not sure how to express in the linkrels that editing of the child policy must be done by POSTing the parent document.
The reason for noting this asymmetry in the REST API profile is to reduce the REST API exposure to the semantics of how version numbers change in revisions, particularly between different policies. Asymmetric operations on child policies allow for implementations
to manage version propagation internally when changes are made to a child policy. When making a change to a contained child policy, it’s usually the case that the parent / container also needs to have its version bumped, all the way up the parent chain to
the root node, in order to preserve the semantics of the container prior to the child revision. This is not an issue for external policy/set references.
-Danny
Danny Thorpe
Product Architect |
| Quest Software -
Now including the people and products of BiTKOO |
www.quest.com