On Wed 27 Jan 2010 10:25:37 Kasemir, Kay wrote:
> Looks OK overall, just some comments.
>
Thanks a lot for the feedback!
> Case Sensitivity
> "..tags and property names are forced to be lower case"
> yet the example shows tag name="joesQuaps".
> Would "joesQuaps" cause an error,
> or will it be stored as "joesquaps"?
>
Oooops. Got me!
As tags are not implemented yet and that part of the example stuff is
made up ... the service will store it as "joesquaps", so I better get my
examples right....
> Mapping of owner to tag/property
> "All properties with the same name resp. all tags with the same name must
> have the same owner."
> OK, so the "domain" property always has an owner "irmis".
> The representation seems to duplicate the owner with each data element:
>
> <channel ...
> <property name="domain" value="storage ring" owner="irmis"/> ...
> <channel ...
> <property name="domain" value="cafeteria" owner="irmis"/> ...
> <channel ...
> <property name="domain" value="injetor" owner="irmis"/> ...
>
> Would it make sense to store the mapping of owners to element types
> elsewhere, not duplicate it with each instance of an element?
>
This is redundant, correct. I was thinking about normalizing it out to
another table, but this would increase complexity (number of tables goes
up by 50% ;-), and I got slightly worried about losing query
performance. It would also probably make the owner attributes in the
payload optional (as at least one is needed for a new property, but none
for existing properties), leading to more options, complexity and
business logic for the payload.
I decided for the time being to stick with simple approach and just
throw an error if the payload is not consistent. I would guess that in
most cases an application would manipulate stuff by query - update -
submit anyway.
> Queries
> Is it true that "Tag" and "Name" cannot be property names, since
> Tag=... resp. Name=... search for those,
> while anything_else=.. looks for entries with matching properties?
> Or are only queries with "Tag=...", i.e. an uppercase Tag filtering on tags,
> while "tag=..." would look for entries where the property with
> name "tag" matches, property names always being lowercase?
>
The latter. "Special" names are checked for first, else the string is
forced lowercase and treated as a property name. That allows for any
special names without restricting the property namespace.
> API in general
> On one hand, your service API is neat because it's minimal compared to
> say XML-RPC. On the other hand, it's hard to remember the difference between
> PUT and POST with for example
>
> .../tags/<name>
> Payload: List of Channels
>
> Maybe it's more obvious and thus avoids some errors if you change that to
>
> .../set_tags/<name>
> Method: PUT or POST
> Payload: List of Channels
>
> resp.
>
> .../add_tags/<name>
> Method: PUT or POST
> Payload: List of Channels
>
PUT on an entity is always idempotent and overwrites the entity itself,
while POST on an entity creates or updates subordinate entities.
I think this behavior is well-defined and not being argued about. (At
least I didn't find any different opinion anywhere.)
Of course, your suggestion is more obvious, but ... hmmm ... I will
think about it. I am somewhat reluctant, though, as imho the URL should
only identify namespace and entity, not the action. (I know many
existing web service APIs don't stick to that rule, though.)
Again: thanks a lot for your input, which is highly appreciated!
Cheers,
Ralph
|