Updates for PR-202

[PaperMtn]

Small adjustments for [#202]

• Use secops/chronicle/utils/format_utils.parse_json_list() helper where appropriate
• Use secops/chronicle/utils/format_utils.format_resource_id() helper where appropriate for consistent parsing of resource ID, regardless of whether a full path is passed or not
  • E.g: if the full path projects/12345/locations/eu/instances/.../123-ID-abc is passed, it is extracted to 123-ID-abc
  • 123-ID-abc is also accepted

Prefer the use of a "None-filtering" pattern for body/param building

When building params or body values, replace the usage of

if x is not None:
    body[x] = x

if y is not None:
    ...

With a more efficient "None-filtering" pattern, where the dict is defined with all possible variables from the function, then any empty values removed:

body = {
    "x": x,
    "y": y,
    "z": z,
}

body = {k: v for k, v in body.items() if v is not None}

[mihirvala08]

Below approach seems more inefficient to me. We are building object and then immediately rebuilding same object, which can lead to extra memory allocation and overhead.

body = {
    "x": x,
    "y": y,
    "z": z,
}

body = {k: v for k, v in body.items() if v is not None}

Old approach seems better option to me, but there is another option we can look into is having utility method to remove none values (example below)

def remove_none_values(d: dict) -> dict:
    """Remove keys with None values from dictionary."""
    return {k: v for k, v in d.items() if v is not None}

params = remove_none_values({
    "pageSize": str(page_size),
    "pageToken": page_token,
    "tenantId": tenant_id,
})

[PaperMtn]

I think the overhead will be negligable on this scale. The benefit of this approach is when building larger params or body dicts it makes the code a lot more readable, instead of a long list of if statements, it makes each field's intent specific.

Replacing it with a helper could potentially make the code more readable by wrapping the comprehension in a function that the user doesn't have to see.

[mihirvala08]

I think the overhead will be negligable on this scale. The benefit of this approach is when building larger params or body dicts it makes the code a lot more readable, instead of a long list of if statements, it makes each field's intent specific.

Replacing it with a helper could potentially make the code more readable by wrapping the comprehension in a function that the user doesn't have to see.

Understood!
So, if we are to go ahead with "filtering out" approach, let's use helper/utility function to filter-out nones from dict to make it more readable.

[PaperMtn]

@mihirvala08 I've implemented the helper in my latest commit