Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implement custom state check #61

Conversation

arielsepton
Copy link
Member

PR Description: Add expectedResponseCheck for Custom Response Validation

Summary

This PR introduces a new feature, expectedResponseCheck, which allows users to define custom logic for validating the response of HTTP requests. This enables more flexible and dynamic checks to determine if the actual response matches the expected state.

Key Changes:

  • expectedResponseCheck Field: Added to RequestParameters to enable custom response validation.
    • Supports two types:
      • "DEFAULT": Uses the current behavior of comparing if the PUT body is contained within the GET response.
      • "CUSTOM": Allows users to define their own validation logic using JQ expressions for more advanced response checks.
  • Custom Logic: The logic field within expectedResponseCheck enables users to write JQ expressions that compare elements such as response body fields and headers to custom values or other parts of the request.
  • Example:
    • A sample CUSTOM logic:
      expectedResponseCheck:
        type: "CUSTOM"
        logic: |
          if .response.body.email == .payload.body.email and .response.body.age == 30 
          and .response.headers."Content-Type" == ["application/json"]
          then true else false end

Benefits:

  • Enhanced Flexibility: Users can apply more advanced validation logic based on their specific use cases, allowing fine-grained control over when a response is considered valid.
  • Backward Compatibility: The DEFAULT type retains the current behavior, ensuring no breaking changes for existing users.
  • Custom Validation: Custom JQ expressions allow for validation beyond simple field matching, including the ability to compare headers, status codes, or other complex response structures.

Motivation:

This feature is designed to address use cases where the default validation logic might not be sufficient, allowing for custom transformations and checks that ensure the response aligns with the expected state of the resource.

I have:

  • Read and followed Crossplane's [contribution process].
  • Run make reviewable test to ensure this PR is ready for review.

Fixes #59

@arielsepton arielsepton force-pushed the feat/implement-custom-logic-for-response-comparison branch 2 times, most recently from 2fb2a2f to ba412a9 Compare October 1, 2024 20:05
Signed-off-by: Ariel Septon <arielsepton@Ariels-MBP.lan>
@arielsepton arielsepton force-pushed the feat/implement-custom-logic-for-response-comparison branch from ba412a9 to 2974e3f Compare October 1, 2024 20:09
@arielsepton arielsepton merged commit 14e486a into crossplane-contrib:main Oct 1, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Request object / expected response in GET
1 participant