如何以RESTful方式实现按需验证挑战的结账流程？

Great question! Let's break down how to implement this adaptive checkout flow in a RESTful way, sticking to core REST principles like resource orientation and stateless interactions.

Core Resource Modeling #

First, anchor the design around REST's resource-first mindset:

• Primary Resource: Checkout - Represents a single checkout attempt, including user payment details, selected items, validation state, and final outcome.
• Subresource: Challenge - A validation task tied to a specific checkout (only exists if the checkout requires verification).

Key API Endpoints & Workflow #

Map each step of your flow to RESTful endpoints with clear, intuitive semantics:

1. Initialize Checkout (User Clicks "Checkout" Button) #

Endpoint: POST /checkouts
Request Body:

{
  "creditCard": {
    "number": "4111-1111-1111-1111",
    "expiry": "12/25",
    "cvv": "123"
  },
  "cartItems": [
    { "productId": "prod_123", "quantity": 2 },
    { "productId": "prod_456", "quantity": 1 }
  ],
  "userId": "user_789" // Optional, but critical for historical record checks
}

Server Logic:

• Validate request data (CC format, valid product IDs, etc.)
• Assess user suspiciousness by cross-referencing real-time signals (unusual location, high-value order) with historical checkout records
• Two possible responses:
  • Case 1: No challenge needed:
    • Process payment, save the completed checkout record, return 201 Created with final details:

    {
      "id": "checkout_abc123",
      "status": "completed",
      "totalAmount": "$99.99",
      "paymentMethod": "Visa ending in 1111",
      "orderId": "order_xyz789"
    }
    

  • Case 2: Challenge required:
    • Create a pending checkout record (encrypt CC details temporarily), generate a challenge matching the suspiciousness level (e.g., captcha for low risk, SMS OTP for high risk)
    • Return 202 Accepted with checkout ID and challenge instructions:

    {
      "id": "checkout_abc123",
      "status": "pending_challenge",
      "challenge": {
        "type": "sms_otp",
        "challengeId": "challenge_456",
        "expiresAt": "2024-05-20T14:30:00Z",
        "instructions": "Enter the 6-digit code sent to your phone (555-1234)"
      }
    }
    

2. Submit Challenge Result #

Endpoint: POST /checkouts/{checkoutId}/challenges
Request Body:

{
  "challengeId": "challenge_456",
  "response": "123456" // OTP, captcha token, or other challenge response
}

Server Logic:

• Fetch the pending checkout record using checkoutId
• Validate the challenge response against the generated task
• Outcomes:
  • Valid response:
    • Process payment, update checkout status to "completed", return 200 OK with final checkout details (same as the 201 response above)
  • Invalid response:
    • Return 422 Unprocessable Entity with actionable error, optionally allow retries based on risk rules:

    {
      "error": "Invalid OTP code. Please try again.",
      "remainingRetries": 2
    }
    

  • Challenge expired:
    • Return 400 Bad Request with:

    {
      "error": "Challenge has expired. Please restart the checkout process."
    }
    

  • High-risk failure:
    • If the user fails multiple challenges, mark checkout as "rejected" and return 403 Forbidden:

    {
      "error": "Checkout rejected due to suspicious activity. Please contact support."
    }
    

Critical RESTful Best Practices #

• Statelessness: Avoid storing session state between requests. All context (like pending checkout data) is tied to the checkoutId passed in requests.
• Idempotency: Add support for an Idempotency-Key header on POST /checkouts to prevent duplicate checkout attempts if the client retries accidentally.
• Resource Hierarchy: The Challenge subresource is clearly tied to a specific Checkout, aligning with REST's hierarchical resource model.
• Semantic Status Codes: Use HTTP status codes that accurately reflect outcomes (201 for completed checkouts, 202 for pending challenges, 422 for validation failures, etc.)

Additional Considerations #

• Temporary Data Security: When a checkout is in pending_challenge state, encrypt and temporarily store payment details with an expiration time (e.g., 15 minutes) to comply with PCI-DSS.
• Dynamic Challenge Difficulty: Return different challenge.type values based on risk level (e.g., captcha for low risk, multi_factor for high risk) — the client should handle each type gracefully.
• User Guidance: Include clear, user-friendly error messages in response bodies to help clients guide users through retries or next steps.

内容的提问来源于stack exchange，提问作者Christopher Smith