Use TECHNOLOGY_LIFTWEB and TECHNOLOGY_HTTP4S constants from Constant object
instead of inline string literals "lift" and "http4s" across codebase.
This improves maintainability and reduces risk of typos.
Refactor executeAndRespond to properly handle exceptions from Future and convert them to HTTP responses using ErrorResponseConverter. This ensures consistent error handling across HTTP4S endpoints.
Simplify error response creation by parsing APIFailureNewStyle exceptions from JSON message instead of direct type matching, making error handling more robust.
Update API version validation in Http4s700 to use NewStyle.function.tryons and Helper.booleanToFuture for consistent error handling patterns.
Adjust test to use proper error message constant for invalid API version.
Add integration tests to verify that the /resource-docs endpoint returns only http4s technology endpoints and rejects requests for non-v7 API versions. This ensures proper filtering and version handling in the http4s routes.
- Replace hardcoded API version strings with ApiVersion constants in JSON factories and API methods
- Add new ApiVersion constants for Bahrain OBF and AU Open Banking
- Update test to use ApiVersion constants for version strings
- Ensure consistency and maintainability across API version references
Replace hardcoded "v7.0.0" string with ApiShortVersions.`v7.0.0`.toString in ResourceDocMiddleware and update test files accordingly to use the constant. This ensures consistency and easier maintenance when API version references need to be updated.
Add `technology` field to `implemented_by` JSON to indicate whether an endpoint is implemented using lift or http4s. The field is included only when `includeTechnologyInResponse` is true, which is set for API versions 6.0.0 and 7.0.0. This helps API consumers understand the underlying implementation technology.
Update tests to verify technology field presence/absence based on API version. Also improve test setup robustness by making user and account creation idempotent, and update build dependencies to support http4s and pekko.
Move role-based authorization for resource-docs endpoint from endpoint implementation to ResourceDocMiddleware. This ensures consistent authentication handling across all endpoints and removes duplicate authorization logic.
The middleware now checks the `resource_docs_requires_role` property and enforces the `canReadResourceDoc` role when enabled. Tests are updated to verify proper 403 responses with missing role messages.
- Safely extract request headers using `S.request.map(...).openOr(Nil)` instead of `openOrThrowException`
- Add proper error handling for resource-docs endpoint using `ErrorResponseConverter`
- Extract query parameters directly from URI instead of parsing URL string
- Add comprehensive test suite for Http4s700 routes
- Ensure all responses (errors and successful) have JSON Content-Type
- Replace repeated EitherT patterns with a clean Validation DSL (success/failure)
- Add ValidationContext to accumulate user, bank, account, view, and counterparty entities
- Add detailed comments for authentication, authorization, and entity validation steps
- Simplify middleware logic while preserving original validation order and behavior
- Add comprehensive test suite for ResourceDocMatcher with 545 lines of test coverage
- Test exact path matching for GET, POST, and multi-segment paths
- Test verb and path mismatch scenarios returning None
- Test BANK_ID variable matching and parameter extraction
- Test BANK_ID + ACCOUNT_ID variable matching and extraction
- Test BANK_ID + ACCOUNT_ID + VIEW_ID variable matching and extraction
- Test COUNTERPARTY_ID variable matching and extraction
- Test non-matching request scenarios
- Ensure ResourceDocMatcher correctly identifies and extracts path parameters for all variable types
- Use FeatureSpec with Given-When-Then style for clear test documentation
- Add Http4sCallContextBuilderTest with 454 lines of test coverage
- Test URL extraction including path, query parameters, and path parameters
- Test header extraction and conversion to HTTPParam format
- Test body extraction for POST, PUT, and GET requests
- Test correlation ID generation and extraction from X-Request-ID header
- Test IP address extraction from X-Forwarded-For and direct connection
- Test authentication header extraction for all supported auth types
- Test error handling and edge cases in CallContext building
- Ensure Http4sCallContextBuilder correctly processes http4s Request[IO] objects
- Add EndpointHelpers object with reusable endpoint execution patterns
- Implement executeAndRespond helper for Future-based business logic execution
- Implement withUser helper to extract and validate User from CallContext
- Implement withBank helper to extract and validate Bank from CallContext
- Implement withUserAndBank helper for endpoints requiring both User and Bank
- Add comprehensive documentation and usage examples for each helper
- Import EndpointHelpers in Http4s700 for endpoint implementation
- Reduce boilerplate in endpoint implementations by centralizing common patterns
- Improve code consistency and maintainability across http4s endpoints
- Replace withCallContext helper method with implicit RequestOps extension class
- Add `req.callContext` syntax for cleaner CallContext extraction in endpoints
- Enhance Http4sRequestAttributes documentation with usage examples
- Update Http4s700 endpoints to use new implicit CallContext accessor pattern
- Remove nested callback pattern in favor of direct implicit CallContext availability
- Improve code readability by eliminating withCallContext wrapper boilerplate
- Add RequestOps import to Http4s700 for implicit extension method support
- Add withCallContext helper method to Http4sSupport for simplified endpoint code
- Document use of http4s Vault for type-safe request attributes storage
- Clarify that validated entities (bank, bankAccount, view, counterparty) are stored within CallContext
- Reorder validation chain in ResourceDocMiddleware to check roles before entity validation
- Add special handling for resource-docs endpoint with configurable role requirement
- Extract runValidationChain method to support both middleware and endpoint wrapping patterns
- Improve authentication error handling with better Box pattern matching
- Add comprehensive documentation and usage examples for CallContext extraction
- Enhance logging for validation chain execution and debugging
- Add bank, bankAccount, view, and counterparty fields to CallContext case class
- Remove individual Vault keys for User, Bank, BankAccount, View, and Counterparty from Http4sRequestAttributes
- Simplify Http4sRequestAttributes to store only CallContext in request attributes
- Update ResourceDocMiddleware to enrich CallContext with validated entities instead of storing them separately
- Remove ValidatedContext case class as validated entities are now part of CallContext
- Streamline request attribute management by centralizing all validated data in a single CallContext object
- Improves code maintainability and reduces complexity in the validation chain
entitity endpoints now return records created by user_id even if not via
/my endpoints (i.e. if created with another endpoint that requires a
role, the record is still yours)
