atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hemanth Yamijala (JIRA)" <>
Subject [jira] [Commented] (ATLAS-305) API: Provide Hierarchical Trait API
Date Tue, 17 Nov 2015 10:30:11 GMT


Hemanth Yamijala commented on ATLAS-305:

Some questions / clarifications before proceeding to implementation:
* The current set of APIs that deal with types (including traits) are /types?type=TYPE_DEFINITION_NAME
and /types/{type_name}. The first one returns a list of type names as strings; the second
returns the type definition for the specified type.
* So, to implement this change a couple of options are:
** Extend current API: */types?type=TYPE_DEFINITION_NAME&view=EXPLORE*: If the additional
parameter is specified we can return a type_name=>list of parent type_names. This additional
parameter clearly specifies what additional information is required. However, it seems like
an ad-hoc extension to the API for a specific use case. Some inspiration for this [here|]
** Extend current API: */types?type=TYPE_DEFINITION_NAME&fields=parents*: The additional
parameter fields tells us what other fields should be returned in the response. This leaves
the system flexible to add more information in a consistent fashion. However, implementing
this for all fields is beyond the scope of this JIRA and is possibly making it more complex.
Apparently, this is how Google, Facebook etc specify optional information in their APIs as
specified [here|].
** A new API altogether; which would be a good option if we can agree on an API that seems
* The other point is regarding the response. What would possibly be ideal is a response of
the sort of:
"results": [
  {"type_name": "xyz", "parent_type_names": [{"type_name": "abc"}]
which I think leaves it open to extend if needed.
** However, since the current APIs only send a list of strings as response, extending them
as in Options 1 and 2 above would not be possible without breaking the API, and hence necessitate
larger changes like versioning etc.
* The use case currently as seen from ATLAS-210 is to display the traits hierarchically in
a UI - to support cases of browsing / exploring the type system in an Atlas instance. A couple
of points about this:
** Traits (as also classes) can have multiple super types. Having a hierarchy will mean that
the same child will come multiple times under multiple parents. Not sure if a hierarchy is
still the most suitable representation.
** The proposed response still will need UI work to re-arrange the results to group children
under a parent. However, in this design only the required minimal information is sent from
server to client, and the implementation is also going to be fairly performant on the server
** Overall, I felt the API we design should also cover other types like Classes, because we
may need to show them as well similarly in the UI.

Please do comment what you think about the options proposed.

> API: Provide Hierarchical Trait API
> -----------------------------------
>                 Key: ATLAS-305
>                 URL:
>             Project: Atlas
>          Issue Type: Bug
>    Affects Versions: 0.6-incubating
>            Reporter: Erik Bergenholtz
>            Assignee: Hemanth Yamijala
> Currently, the UI displays the tags in a flat structure, even though traits have a hierarchical
structure. The primary reason for this is the API that returns the list of traits does not
provide the hierarchical structure.
> Atlas should provide a single API that provides a response that includes the hierarchical
structure of the existing set of traits.
> Tag 1
> -- Tag 1.1
> ---Tag 1.1.1
> Tag2
> -Tag2.1
> etc.
> This is related to: ATLAS-210

This message was sent by Atlassian JIRA

View raw message