[MGNLRESTCL-146] Refactor DefaultRestClient invocation, parameterization and error-handling Created: 09/Mar/20 Updated: 19/Mar/20 Resolved: 18/Mar/20 |
|
| Status: | Closed |
| Project: | REST Client |
| Component/s: | API |
| Affects Version/s: | 2.0 |
| Fix Version/s: | 2.0 |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Mikaël Geljić | Assignee: | Mikaël Geljić |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | 0.25d | ||
| Time Spent: | 1d 6.5h | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||
| Epic Link: | Declarative REST clients | ||||||||
| Sprint: | 6.2 Ramp-up 19, 6.2 Ramp-up 20 | ||||||||
| Story Points: | 5 | ||||||||
| Description |
|
Current DefaultRestClient impl has several indirections from invoke methods to one another, up to a chain of delegation involving 2 public methods + 2 private methods, all responsible for various aspects of building the invocation (invocation itself, parameterization, error-handling). Proposing to address that while expanding RestClient's invoke capabilities to take (optionally) an error-handler, passed from the consumer (knowing best what to do then). At the same time, we reckon #invoke method accepting whole request body as argument needs to go, in favor of declared bodies in rest calls, and support for template values there. restfn may as well accept an error-handler. |