[
https://issues.apache.org/jira/browse/ATLAS-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093146#comment-16093146
]
Nigel Jones commented on ATLAS-1698:
------------------------------------
A few thoughts
* I notice the swagger API rendering from the build is a lot weaker/less
readable that swagger.io or the standalone editor. I wonder if it needs
updating? DO you know what tool it uses?
* In the OCF documentation a series of scoping parameters is suggested. I
tried to incorporate these into
https://issues.apache.org/jira/browse/ATLAS-1696 (GAF OMAS) though the
relevance of each is dependent on the specific omas/operation, and in
particular is of most relevance to search/set operations rather than retrieval
by guid. We should also decide on what consistency is needed for the way these
are scoped. It seems query parms work nicely for a GET.
* We need to decide how to determine which OMRS to use for this OMAS. This
could be statically configured (property etc) and the same for all apps, or
could be provided by the caller. The OCF document suggests it's
caller-specified, so I included "metaData connection" as a query parameter
* I don't think zone applies to most glossary operations, but might become
relevant when you are returning a graph. Your proposal will filter the type of
data returned, but do we need filtering also such as this once we go down to
assets?
* locale? Is this needed? It can affect sort-ordering for example, not just
term translation?
* namespace guid is a concept we've discussed using to allow for seperate
glossaries between development, test, production (with a default)
* tenant is also proposed as a common scope parm - this definately applies here
* "asOfQueryTime" is used for point in time queries
Also for responses I see 200 listed, but we also should have clear mappings for
other conditions & express the http response code + payload.
I tried to do this in my swagger api doc
In a previous face to face discussion the suggestion that all our
implementations should have a built-in "limit" (the max results we can return)
in addition to that espressed on the UI. A safety mechanism. probably set as a
property?
For each OMAS we also need to document the Kafka topics it consumes and
produces (I've not yet done this thoroughly for mine either!)
> Create Glossary OMAS API
> ------------------------
>
> Key: ATLAS-1698
> URL: https://issues.apache.org/jira/browse/ATLAS-1698
> Project: Atlas
> Issue Type: Sub-task
> Reporter: David Radley
> Assignee: David Radley
> Labels: VirtualDataConnector
> Attachments: apidocs-5.zip, Atlas Glossary OMAS API proposal v1.0
> .pdf, Atlas Glossary OMAS API proposal v1.1.pdf, Atlas Glossary OMAS API
> proposal v1.2.pdf
>
>
> The Glossary OMAS provides a specialized API for glossary applications to
> retrieve and store their glossary metadata and link assets of different types
> to these glossary entries.
> The Glossary OMAS makes heavy use of the Area 2 open metadata model. See
> https://cwiki.apache.org/confluence/display/ATLAS/Area+2+-+Glossary
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
