Maintenance: Audit & reduce public API surface area

[scottgerring]

Summary

As part of the V2 improvements we have an opportunity to work on public-facing API changes. We should reflect on our current API surface and where there is room for improvement in terms of what is exposed to the user. Where we make a change from V1, we should document a migration path.

Why is this needed?

As it stands we have quite a large API surface area that can 1/ make it difficult for customers to use the API ("which one of these options should I use to interact with this module?) and 2/ make it difficult to maintain the modules, as any public API cannot be changed.

Which area does this relate to?

No response

Solution

No response

Acknowledgment

• [X] This request meets Powertools for AWS Lambda (Java) Tenets
• [ ] Should this be considered in other Powertools for AWS Lambda (Java) languages? i.e. Python, TypeScript

[scottgerring]

This has been done for some modules:

• Batch: #1317
• Large messages: #1310
• Metrics: #1041
• Logging: #1435

This will be done for the other modules:

• Idempotency: #1467
• Parameters: #1403
• Tracing: #1468
• Validation: #1469
• Serialization: #1470