OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (CAMP-188) Optionally serialize Entities alongside Links

    [ https://issues.oasis-open.org/browse/CAMP-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59597#comment-59597 ] 

Gilbert Pilz commented on CAMP-188:

I've been wondering if it would make sense to add a query parameter to the collection resources that could be used to specify which attributes of the referenced resources were included in the links (in addition to the already specified 'name').

For example, you could do a GET on '../campSrv/Assemblies&include=description,plan_uri' and you would see something like:

  name: "nCAMP Assemblies",
  type: "assemblies",
  assembly_links: [
      href: ".../Assembly/112",
      name: "VitaMinder",
      description: "Vitamin and Supplement Tracking",
      plan_uri: ".../Plan/101"

We could reserve a keyword like "!all" to mean "include all of the attributes of all of the referenced resources".

Is this over-complicating things?

> Optionally serialize Entities alongside Links
> ---------------------------------------------
>                 Key: CAMP-188
>                 URL: https://issues.oasis-open.org/browse/CAMP-188
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>    Affects Versions: 1.2
>            Reporter: Mike Norman
>            Priority: Minor
> IN the List resources, the Links are name/href pairs.  This means that if you have a client widget such as a table which displays attributes (other than just the name) of, for example, assemblies it needs to retrieve the assemblies and then iterate through the LInks array retrieving the underlying entities. This is do-able, but it is very unconventional and makes the API very chatty.  You would normally expect the Links entities to be actual json lists containing the attributes.
> Clearly there has been a design decision to allow the implementation to be decoupled at these URIs, but this si the exception not the rule so we need to consider whether there is a way of making the general case less chatty.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]