feat: add resource name in POST path requests #338
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, we only add the resource name in the path for GET requests:
fetchr.read('resource-name')
=>/api/resource-name
.But we never do it for POST requests:
fetchr.read('resource-name').params(hugePayload)
=>/api
.This behavior makes it hard to build monitoring tools on top of it. For example, one could have a gateway in front of
fetchr
that monitors the response success rate per path and triggers an alert if the rate drops. For GET requests, it is easy to spot which resource is the faulty one, but for POST requests it's just impossible without diving into the logs of the service where fetchr is running. It's definitely doable, but not easy if the team that manages the gateway have no idea what is behind it.Another challenge would be to add a circuit breaker per resource. Currently we would need to parse the whole request to implement it (which requires knowledge about how fetchr works internally). But if we always have the resource in the path, then it would be way easier.
In this PR, I just did the least effort change: add the resource in the path if user haven't provided a custom path. But if you think the general idea is valid but the implementation could be different, as always, I'm open to change it :)
I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.