Reevaluate Plater API #104
Description
It has been a while since we looked at the non-TRAPI and translator endpoints of the Plater API. It's not clear if people are using the one_hop, node, and simple_spec endpoints or for what purposes.
For one_hop and node, I think the parameters should be changed. Specifically, they both contain redundant/unnecessary parameters. They also use the base url path without an explicit endpoint, which I think could be confusing and potentially cause issues calling them unintentionally.
one_hop
/{source_type}/{target_type}/{curie}
returns one hop paths from source_type with curie to target_type, but if the curie is specified, I'm not sure why the source type also needs to be specified. This could be changed to something like the following without losing functionality:
/one_hop/{curie}/{target_type}/
node
/{node_type}/{curie}
Returns a node matching curie.
Similarly, these parameters seem redundant to me, the node_type could be removed without losing anything.
simple_spec
/simple_spec with optional source and target url parameters
"Returns a list of available predicates when choosing a single source or target curie. Calling this endpoint with no query parameters will return all possible hops for all types."
This endpoint is somewhat redundant with meta_knowledge_graph, except that it returns less information. It's based on edges and has no nodes section, so it has no node curie prefixes or attributes, or edge attributes. It only includes leaf node types, not every permutation. It gives the option to pre-filter for specific nodes, but without a use case I'm not sure how helpful that is. It also queries the neo4j every time for results and doesn't cache anything, so it can be slow. For that reason, I reworked simple_spec recently so that it returns a cached pre-computed result when parameters are left blank (the full simple spec), because that was especially slow for large graphs (but currently this doesn't filter for leaf node types). I wonder if we should be querying neo4j for this, if we should be caching results, if this should just be part of the meta_knowledge_graph endpoint, or if we need it at all.
I could see us adding additional functionality as well. Should we support N-hop queries from a pinned node to a target type or something like that? Should we add endpoints related to subclass hierarchies?
Additionally, we recently combined the /1.4/ endpoints with everything else, which results in all of these being exposed on the smartapi registry. We could probably fairly easily split them out again if we wanted.