[snip]
> Yes this would be possible. However, there's also a question
of how to show relationship semantics. For the first time I think, we hit the issue in API
that the name of the attribute is different from the resource name. The attribute in
question is not called "user", it is called "owner". I'd kinda
like to indicate this somehow in the response for two reasons:
>
> * Simply to make clear what the relationship means. It's the same reason why our
data model has the relationship named "owner", not "user". I believe
this information shouldn't get lost.
>
> * In case there are multiple users linked to a deployment (or sth else) in the
future, we'd *have* to indicate semantics to avoid ambiguity of having two
<user> links.
>
> Maybe this could be indicated by <user rel="owner" ... />. I'm
not sure of this and it's not a priority question right now, but imho it's a
reason for not putting the <user> there at all for now.
The other question here is really about whether the owner/user should be exposed in the
API ever. Do users need to know this information or is it simply an implementation
detail.
Is there any value in showing the user who owns an image? What can they do with this
information? When we are writing the API we should not blindly copy the database models.
We need think about what makes sense.
Good point. I'm leaving <user> out for now.
[snip]
>>>>> 4) <deployable-xml>
>>>>>
>>>>> *Should we wrap the deployable template into CDATA or not?* The
benefit is that the inner XML will not be parsed by the client when parsing the API
response, so an error in the template XML can't break the whole API response. And it
is semantically cleaner, because the template XML won't be part of the API response
XML tree, but will be treated as data, which it is.
This CDATA concept is very strange to me. The original reason for us using CDATA was
because of the initial crappy implementation we had in the images API. Template is a
resource just like any other. We should parse it and validate it like any other.
>>>>> (Think if we provided JSON API, then the template XML would be
treated as a data too and not converted into a corresponding JSON structure, I'd say.)
The drawback is that our deployable then can't have a CDATA in it, because CDATA
nesting is not allowed. For deployable templates, this might not be a problem right now,
but I wonder about the future. E.g. for image templates it would be a problem [3]. So
I'm sort of on the fence here, maybe a bit in favour of not wrapping it into CDATA.
(Btw Tim solves this by having image template as a separate resource, but I'm not sure
we should go this way for deployables !
CDATA is only relevant when we are using an XML parser. Having this attribute in JSON
means nothing. Tim treats Templates just like any other resource. We do not need to tell
the parser to ignore it's content.
Hmm that's interesting. So if/when Tim wants to provide JSON API, it would accept the
template not as string with XML in it, but as fully structured JSON? And then convert the
JSON into a corresponding XML representation before saving it to the database? (Because
templates are saved in the DB as XML strings [1]...)
So far I thought of templates as "always XML by definition", and I thought they
would be better treated as simple strings on the APIs. I'm not keen on the idea that
if/when we decide to make JSON APIs, we'll also have to invent JSON variant of TDL for
images, deployables, ...
[1]
https://github.com/aeolus-incubator/tim/blob/master/app/models/tim/templa...
[snip]
>
> Unless I missed something important, I'm tempted to go the way of simple
embedding without CDATA, as Richard suggested.
>
>
+1
Ok, so I think we can pronounce this a consensus :) Thanks everyone.
J.