connexta / ddf-jsonrpc Goto Github PK

Return query response properties. Might need to use an allow or block list to protect sensitive attributes from returning.

https://open-rpc.org/
https://spec.open-rpc.org/

https://github.com/connexta/ddf-jsonrpc/blob/master/ddf-rpc-api/src/main/java/com/connexta/ddf/catalog/direct/CatalogMethods.java#L394-L395

Timeout may or may not be safe to let clients send (could be security risk)

Split out the core of JSON RPC endpoint into a new module. Split out other method sets into other modules. Allow method sets to be dynamically loaded into the JSON RPC endpoint.

Currently we only send the metacardType name of the associated metacard. There should be a way to get the full attribute definitions of the metacardType.

An Optional extra step, allow it to be requested/excluded on demand since it will add a fairly large amount of (repetitive) data to the payload.

Something else to think about that will build on top of this is somehow identifying the metacardTypes with an absolute identifier (perhaps a hash) so that types could be only requested if the definition is not already known.

Update dependencies but remove any unnecessary dependencies (large dependencies used for a few classes) first.

We should add support for properties so that we can more fully support the catalogframework api. Many things use properties to propagate extra information.

Since there are security concerns we should have an allow list of properties that are allowed to be sent and added to the corresponding request sent to catalog framework.

Add support for transforming metacards akin to the CatalogFramework methods transform

BinaryContent transform(
      Metacard metacard, String transformerId, Map<String, Serializable> requestProperties)
      throws CatalogTransformerException;

BinaryContent transform(
      SourceResponse response, String transformerId, Map<String, Serializable> requestProperties)
      throws CatalogTransformerException;

One thing to think about with this is how the input is provided over the remote interface. Does the caller need to supply the full data (aka metacard, sourceresponse, etc) and have it be reconstructed by us? Can we do some sort of value by reference where the caller can supply reference to metacards,etc that are desired and the querying can be done by us?

Instead of silently working and assuming or silently dropping when creating metacard attributes, we should work to return helpful error messages of what went wrong and why for consumers to know why an attribute wasn't included or such.

One possible implementation could be by changing the CatalogMethods::getAttribute method to somehow return more information (possibly a third piece of information?) on if attributes were found to have issues.

Catalog methods should only contain 1 to 1 mappings to the catalog framework API.

Add the ability to get resources akin to the CatalogFramework methods get*Resource

Currently Metacard actions are coupled to the query response results. Metacard actions are obtained by using a different api (from platform) and should not be represented in the data the catalog methods return. This should be separated to its own RPC method and a mechanism devised to get the metacards actions.

Since the interface for ActionProvider is public <T> Action getAction(T subject); There will need to be a way devised to supply the paramter subject to the action provider. This is often times a metacard (and could be represented by a reference to a metacard and then fetched by the jsonrpc) but may not always be a metacard. the fact that an abitrary subject can be passed into this interface will need to be accounted for in the parameters of this rpc endpoint.