Determine best way to handle resource names

[paul121]

As @mstenta summarized in #39:

JSON:API has "resources" (one level), but Drupal has "entities" and "bundles" (two levels). In order to represent Drupal's added bundle level, the Drupal JSON:API module basically creates a separate JSON:API resource for each bundle, with the entity type in the name, like [entity-type]--[bundle]. For example: log--observation.

This is particularly important in determining the arguments for the farmOS client methods. Right now the farmOS.py client.resouce.* methods have separate parameters for type and bundle: client.resource.get(type, bundle, filters). Methods for logs, assets and terms only require a bundle to be provided: client.log.get(bundle, filters).

This is an important DX consideration because the type strings found in a JSONAPI response, such as log--observation, cannot be passed as the first argument to client.log.get(bundle, filters). Similarly, the user--user identifier cannot be passed as either the first OR second parameter of client.resource.get(type, bundle, filter).

Proposed resolution

I think we should consider removing the bundle parameter from client.resource.* methods and instead only accept a type parameter which is assumed to be correctly formatted. The helpers for logs, assets, and terms could continue to use a bundle param, with the limitation that a full type string cannot be provided to these methods.

I know @jgaehring is implementing the type as a special filter since farmOS.js will have the ability to request ALL log types if none are provided. We could do the same for the log, asset and term helper methods, but I'm hesitant. If we don't implement the "request ALL types" functionality, then it becomes required input, which is better implemented as a method parameter IMO.

[paul121]

This also has some implications for the Aggregator URL endpoints. I think we need to implement the type as either path parameters or query parameters

[paul121]

I think we should consider removing the bundle parameter from client.resource.* methods and instead only accept a type parameter which is assumed to be correctly formatted.

Don't think we'll go this route. I don't love that the JSONAPI responses return a type that isn't compatible with the farmOS.py methods, but I think that requiring a JSON API formatted type string would be worse DX. The aggregator resource endpoint will have path parameters for the type and bundle too.

This means that custom code parsing a JSON API response might need to parse a resource's type (eg: log--activity) into separate log and activity strings itself.