Skip to content
CodeKruPro

Compare replacement, partial change and deletion

Automation taskEasy-MediumAsked in: Capgemini, Coupa, Infosys, TCS

Interviewers follow up with: "How do you know the PUT really worked?" The answer is to read the resource back after every change. This lesson builds that habit with PUT, PATCH and DELETE.

Compare replacement, partial change and deletion

02 · Build reusable requests and investigate results

Recommended first: Discover simulated creation by reading back

Your goal: Compare replacement, partial change and deletion

Follow one request at a time. Send it yourself, then select that response before you answer.

  1. 1Send requests
  2. 2Submit answers

Start here: sign in to practise.

Jump to practice

What you will learn

PUT usually expresses replacement and PATCH a partial change, but each API defines exact omitted-field rules. Idempotent means repeated identical requests have the same intended server effect; response codes need not be identical.

Your goals

  • Compare PUT and PATCH response fields.
  • Understand simulated DELETE and idempotent intent.

Before you start

Read the previous lesson first if you have not already. This course does not require programming.

Practice setup

These requests use the public TestKru teaching API. No workspace is needed unless a step says so. Leave the body empty for GET, HEAD and OPTIONS. Example people and emails are fictional. Changes to /api/users are simulated and are not saved.

Follow these steps

  1. Send the PUT and select its response. Compare the fields with what you sent, including any field you left out.
  2. Send the PATCH and select its response. Compare age and email with the original user, not with the PUT reply. These legacy changes are not saved between requests.
  3. Send DELETE and select its response. Look at whether the body is empty.
  4. Send GET for the same id and select its response.
  5. Copy the age from the PATCH response and the status of the later GET. Choose how this API stores changes.
  6. Submit Answers.

Investigate before concluding

First record the actual result for each case. Compare the body, headers and later state with the stated contract. Keep an observation separate from a prediction; use the model answer only after making your own attempt.

What to keep as evidence

  • Replacement and merge examples are compared.
  • 204 empty body is interpreted correctly.
  • Static fixtures are not treated as persistent state.
References for this lesson

Finish this assignment

Select each named response with Use this response. Answer from those responses or the transcript on this page. Click Submit Answers. Your score is the percentage of checks that passed. Core checks are required to finish. Extra evidence checks are labelled. A saved 100/100 means every check passed. Continue opens the next lesson you can submit.

If something goes wrong
  • Change one part of the request at a time. If a check needs attention, read the note under it and compare it with the response you selected.
Self-review and independent variation
  • Replacement and merge examples are compared.
  • 204 empty body is interpreted correctly.
  • Static fixtures are not treated as persistent state.

Repeat a real persistent DELETE in the later real-deletion lesson; its second response can be 404 even though the deletion effect stays idempotent.

Automatic checks verify the requests and answers configured for this lesson. The self-review is for your own reasoning. A score is not a certificate.

Open API reference

Practise and save your evidence

The lesson is public. Sign in to send requests and save progress. You will return to this lesson.

Sign in to practiseCreate an account