RANGER-5577:API for update and delete of resources in DataShare

[rameeshm]

What changes were proposed in this pull request?

Introduced a new API to do the update and delete of resources in the datashare.

How was this patch tested?

Testing in local vm
curl -ikv --negotiate -u : -H "Accept: application/json" -H "Content-Type: application/json" -X PUT 'https://:6o80/service/gds/resource?forceDelete=true' -d '[2,3]'

[mneethiraj]

The API is called UPDATE_SHARED_RESOURCES, but the flag is named a forceDelete. It will help to add a note on the purpose of this API.

[rameeshm]

@mneethiraj we need to use updateSharedResources API to do delete as well, because HTTP DELETE is not accepting payloads and in order to support a bulk delete we are using the flag "forceDelete". Naming the API as deleteSharedResources with PUT doesn't look right, so introduced this flag "forceDelete". Should I have new API list as "UPDATE_OR_DELETE_SHARED_RESOURCES" for this new API? Please advice.
This bulk delete / update will be helpful in the integration of external system which does bulk operations of adding / updating / removing resources in the DataShares.

[mneethiraj]

@rameeshm - GdsREST already has following API to bulk-delete shared resources, which I guess takes a comma-separated list of IDs as query parameter. Does that not work?

@DELETE
@Path("/resources")
@PreAuthorize("@rangerPreAuthSecurityHandler.isAPIAccessible(\"" + RangerAPIList.REMOVE_SHARED_RESOURCES + "\")")
public void removeSharedResources(List<Long> resourceIds) {
...
}

API to bulk-add shared resources also already exists. Perhaps adding an API to bulk-update is good enough? i.e. is an API to update or delete necessary?

[rameeshm]

@mneethiraj the existing API may not be useful.

As per (RFC7321) https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.5
A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. Because of this while the spec does not explicitly forbid bodies, it warns that many servers, proxies, and load balancers may reject or silently ignore them. To overcome this and have a functionality to bulk delete I am using
public void updateSharedResources(@QueryParam("forceDelete") @DefaultValue("false") boolean forceDelete, List<RangerSharedResource> resources)

[mneethiraj]

@rameeshm - would marking resourceIds parameter as @QueryParam("id") help to receive the IDs as query params instead of body?

@DELETE
@Path("/resources")
@PreAuthorize("@rangerPreAuthSecurityHandler.isAPIAccessible(\"" + RangerAPIList.REMOVE_SHARED_RESOURCES + "\")")
public void removeSharedResources(@QueryParam("id") List<Long> resourceIds) {
...
}

Following curl will result in above method to be called with resourceIds containing two entries - 1 and 2:

curl -u user:password -X DELETE "https://ranger/service/gds/resources?id=1&id=2"

[rameeshm]

@mneethiraj we can do that. I thought it would not be right way if the number of ids are more, but I think it should satisfy the requirement.

[rameeshm]

@mneethiraj I am closing this PR and going to open one with the change you recommended.

[rameeshm]

Closed this PR to have a updated version with recommend changes. Need to change the JIRA heading as well for this change, so do this to have a clean history of work.