[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (CAMP-62) JSON arrays of Links are more constrained than the underlying implementation
[ http://tools.oasis-open.org/issues/browse/CAMP-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35841#action_35841 ]
Gilbert Pilz edited comment on CAMP-62 at 11/7/13 2:55 AM:
-----------------------------------------------------------
This issue isn't just about JSON Patch. Here's a simpler example of the problem. It starts by asserting that the majority of CAMP server implementations will *not* maintain serialized versions of the non-metadata CAMP resources - either in memory or in a database. Rather the representations of these resources will be generated from some underlying implementation while servicing a GET request. So suppose a client does a GET on the Assemblies resource. They get back something that looks like the following:
{
"type": "assemblies",
"uri": "http://example.com/campSrv/Assemblies";,
"name": "nCAMP Assemblies",
"assemblyLinks": [
{
"href": "http://example.com/campSrv/Assembly/0";,
"targetName": "Hello World"
},
{
"href": "http://example.com/campSrv/Assembly/1";,
"targetName": "Wherez Waldo"
}
]
}
Now, suppose the same client did the exact same GET a couple of seconds later. If whatever structure or system the CAMP server uses does *not* always return the list of assemblies in the same order, the client could get the following:
{
"type": "assemblies",
"uri": "http://example.com/campSrv/Assemblies";,
"name": "nCAMP Assemblies",
"assemblyLinks": [
{
"href": "http://example.com/campSrv/Assembly/1";,
"targetName": "Wherez Waldo"
},
{
"href": "http://example.com/campSrv/Assembly/0";,
"targetName": "Hello World"
},
]
}
If the Last-Modified header or ETag headers for these two responses are the same, we will likely have a confused clients on our hands. By the rules of JSON the resource has changed (order of elements in an array is significant). To prevent this sort of thing from happening either:
1.) The CAMP server implementation has to internally constrain itself to always generating references to Assemblies in the same order.
2.) The CAMP server has to be sensitive to the fact that the view its presenting of the Assembly resource may "flicker" - and be careful about how it populates the Last-Modified and ETag headers. Basically the resource would always look like it had just been modified a couple of milliseconds after the GET request was received.
I would argue that the constraint in (1) is burdensome and unnecessary because CAMP doesn't care what order the Links appear in in the "assemblyLinks" array. We are imposing constraints on CAMP implementations merely because we've picked a particular representation artifact (the JSON array), not because there is a specific technical reason for that constraint.
I would argue that approach (2) would lead to bizarre behavior and render any attempts to use HTTP caching useless.
was (Author: gilbert.pilz):
This issue isn't just about JSON Patch. Here's a simpler example of the problem. It starts by asserting that the majority of CAMP server implementations will *not* maintain serialized versions of the non-metadata CAMP resources - either in memory or in a database. Rather the representations of these resources will be generated from some underlying implementation while servicing a GET request. So suppose a client does a GET on the Assemblies resource. They get back something that looks like the following:
{
"type": "assemblies",
"uri": "http://example.com/campSrv/Assemblies";,
"name": "nCAMP Assemblies",
"assemblyLinks": [
{
"href": "http://example.com/campSrv/Assembly/0";,
"targetName": "Hello World"
},
{
"href": "http://example.com/campSrv/Assembly/1";,
"targetName": "Wherez Waldo"
}
]
}
Now, suppose the same client did the exact same GET a couple of seconds later. If whatever structure or system the CAMP server uses does *not* always return the list of assemblies in the same order, the client could get the following:
{
"type": "assemblies",
"uri": "http://example.com/campSrv/Assemblies";,
"name": "nCAMP Assemblies",
"assemblyLinks": [
{
"href": "http://example.com/campSrv/Assembly/1";,
"targetName": "Wherez Waldo"
},
{
"href": "http://example.com/campSrv/Assembly/0";,
"targetName": "Hello World"
},
]
}
If the Last-Modified header or ETag headers for these two responses are the same, we will likely have a confused clients on our hands. By the rules of JSON the resource has changed (order of elements in an array is significant). To prevent this sort of thing from happening either:
1.) The CAMP server implementation has to internally constrain itself to always generating references to Assemblies in same order.
2.) The CAMP server has to be sensitive to the fact that the view its presenting of the Assembly resource may "flicker" - and be careful about how it populates the Last-Modified and ETag headers. Basically the resource would always look like it had just been modified a couple of milliseconds after the GET request was received.
I would argue that the constraint in (1) is burdensome and unnecessary because CAMP doesn't care what order the Links appear in in the "assemblyLinks" array. We are imposing constraints on CAMP implementations merely because we've picked a particular representation artifact (the JSON array), not because there is a specific technical reason for that constraint.
I would argue that approach (2) would lead to bizarre behavior and render any attempts to use HTTP caching useless.
> JSON arrays of Links are more constrained than the underlying implementation
> ----------------------------------------------------------------------------
>
> Key: CAMP-62
> URL: http://tools.oasis-open.org/issues/browse/CAMP-62
> Project: OASIS Cloud Application Management for Platforms (CAMP) TC
> Issue Type: Bug
> Components: Spec
> Reporter: Gilbert Pilz
> Assignee: Adrian Otto
>
> Most CAMP resources are related to other CAMP resources in some way. We represent this relationship with the Link type. In cases where a CAMP resource may link to more than one other CAMP resource of the same type (e.g. Application Component Templates may link to one or more Platform Component Templates) we serialize the collection of Link instances using a JSON array. However, the order of elements within a JSON array is significant whereas the order of Links in a CAMP resource is not. We have picked a serialization method (the JSON array) that is more constrained than the semantics of the underlying implementation (a collection of references to other resources).
> The downside of this is that implementers of CAMP will have to write code whose only purpose is to preserve the ordering of the links/relationships between resource even though CAMP doesn't actually care about that ordering.
> For example, the code that implements the JSON Patch support for Link arrays must make sure to preserve whatever order is initially presented to the user. If a user does a GET on an ACT and receives the following:
> {
> "type": "applicationComponentTemplate",
> "uri": "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/ApplicationComponentTemplate/17";,
> "name": "sample",
> "created": "2013-04-13T18:33Z",
> "platformComponentTemplates": [ {
> "href": "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/PlatformComponentTemplate/0";,
> "targetName": "Apache Tomcat 7.0.29"
> },
> {
> "href": "http://ec2-107-20-16-71.compute-1.amazonaws.com/campSrv/PlatformComponentTemplate/1";,
> "targetName": "MySQL Server 5.5.21"
> }
> ]
> }
> then later sends the following PATCH request:
> [
> { "op": "replace", "path": "/platformComponentTemplates/1", "value": '{"href": "http://....}' }
> ]
> the CAMP implementation had *better* replace the link to the database and *not* the link to the appserver!
> It's likely that this JSON Patch example is just the canary in the coal mine. I anticipate many pesky coding problems due to the mismatch between the underlying semantics and the serialization construct that we have chosen.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]