Talk:Web Service API

From CollectiveAccess Documentation
Jump to: navigation, search

I think the draft API looks good. A few really minor suggestions... most/all of which are preference things so feel free to ignore:

  1. For the item-level GET:
    1. We should use the field names as-is rather than "intrinsic_field_N" (I suspect this is what you meant)
      1. Intrinsic fields don't have locales so we don't need to break it out
    2. "related_items" should be "related" - just because we use "items" way too often in other contexts
  2. For the item-level PUT for new records
    1. We should probably use the actual key (eg. entity_id rather than item_id)
    2. "preferred_labels" (and nonpreferred too) can be complex – see entity labels. And nonpreferred ones take a type_id
    3. Since there will be additional relationship fields very soon (effective_daterange, source_info + configurable attributes) we should have provision for that in "related"
  3. For item-level PUT request for existing records
    1. I like having edit and delete operations in a single operation. But perhaps we can make this simpler by just having "delete all values" in there... "replace" in other words since that's what you usually do. And then we can have separate deleteByID calls if you want to delete specific attributes or relationships?
Okay, this all makes sense. 1.2 and 2.1 are easily changed. 2.2.: Oops, I don't know what I was thinking. Of course they are more complex. 2.3: Attributes, too? Then the format must be a lot more sophisticated. Good to know. Lastly, I'm not entirely sure about 3.1 yet. --Stefan (talk) 04:59, 5 October 2012 (EDT)
Also, as for 1.1: Yeah, they don't, but their "decoded representation" might have, for instance access, status and type_id. Since the whole goal of the generic GET is to provide pretty much everything you might need for a detailed record display, I want to include that. --Stefan (talk) 05:02, 5 October 2012 (EDT)
Namespaces

Variants
Actions
Navigation
Tools
User
Personal tools