[ATLAS-1171] Structured, high-level public APIs

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 0.8-incubating
• Assignee: Madhan Neethiraj
• Reporter: Madhan Neethiraj
• Created: 14/Sep/16 16:57
• Updated: 17/May/18 16:02
• Resolved: 02/Oct/16 13:35

Description

Many Atlas APIs use opaque JSON strings (or HTTP request/response contents that are not defined in the interface) to pass details of types/entities - for example here are some APIs:

• TypesResource.submit(HttpServletRequest request)
• TypesResource.update(HttpServletRequest request)
• Response getDefinition(HttpServletRequest request, String typeName)
• Response.getTypesByFilter(HttpServletRequest request, String typeCategory, String superType, String notSuperType)
• EntityResource.submit(HttpServletRequest request)
• EntityResource.updateEntities(HttpServletRequest request)
• Response LineageResource.inputsGraph(String guid)
• Response LineageResource.outputsGraph(String guid)
• Response LineageResource.schema(String guid)
• ..

Also, some APIs expose unnecessary details in the interface, like the one shown below. These look like implementation details which is better not exposed in the interface.

"jsonClass": "org.apache.atlas.typesystem.json.InstanceSerialization$_Reference"

A structured API, with explicit details of the parameters and return value contents, would make it easier to understand the Atlas APIs and create applications that use Atlas services.

I will shortly add a patch that shows the first-cut of this API. Please review and provide your feedback. The initial patch does not include bunch of APIs - like lineage, search, REST, Java API, etc; but it should give a pretty good idea of the data-structures that will be used in the APIs.

Issue Links

• contains: ATLAS-1187 Rename Trait to Classification