Build an OAuth-based data migration client

## Prompt Build a small command-line program that migrates records from a legacy HTTP API to a new HTTP API. ### Required steps 1. **Obtain an access token** using OAuth 2.0 (Client Credentials flow). 2. **Call the legacy endpoint** using the token to fetch data. 3. **Transform the data** according to the rules below. 4. **Send the transformed data** to the new endpoint. 5. **Compute and attach a checksum** for each payload you send. --- ## API contracts (assume these for the exercise) ### 1) Token endpoint - `POST https://auth.example.com/oauth/token` - Body (JSON): - `client_id`, `client_secret`, `grant_type="client_credentials"` - Response (JSON): - `access_token` (string) - `expires_in` (seconds) ### 2) Legacy data endpoint - `GET https://legacy.example.com/v1/records?page=<n>&page_size=<k>` - Header: `Authorization: Bearer <access_token>` - Response (JSON): - `data`: array of records - `next_page`: number or `null` Example legacy record: ```json { "id": 123, "first_name": "Ada", "last_name": "Lovelace", "email": "ADA@EXAMPLE.COM", "created_at_epoch": 1700000000, "status": "ACTIVE" } ``` ### 3) New destination endpoint - `POST https://new.example.com/v2/records` - Headers: - `Authorization: Bearer <access_token>` - `Content-Type: application/json` - `X-Checksum: <checksum>` - (Optional but recommended) `Idempotency-Key: <stable-key>` - Body: one transformed record per request (you can also justify batching if you prefer). --- ## Transformation rules Transform each legacy record into the following shape: ```json { "legacy_id": 123, "full_name": "Ada Lovelace", "email": "ada@example.com", "created_at": "2023-11-14T22:13:20Z", "is_active": true } ``` Rules: - `legacy_id = id` - `full_name = first_name + " " + last_name` (trim extra spaces) - `email = lowercase(email)` - `created_at = created_at_epoch` converted to UTC ISO-8601 - `is_active = (status == "ACTIVE")` --- ## Checksum requirement Compute `X-Checksum` as: - `SHA-256` of the **exact UTF-8 bytes** of the JSON request body you send. - Encode as lowercase hex. (If you choose to canonicalize JSON to avoid key-order differences, explain your approach.) --- ## Non-functional requirements - Handle pagination until `next_page == null`. - Refresh/re-acquire the token when expired. - Retry transient failures (e.g., timeouts, 429, 5xx) with exponential backoff. - Log progress (counts of fetched/transformed/sent; failures with reasons). - The program should be restartable without duplicating writes (idempotency strategy). ### Deliverables - A short design explanation (1–2 pages) describing the approach. - Implementation in a language of your choice. - Tests for transformation + checksum logic, and a strategy for API mocking.