HTTP / LESSON 10

Lab: fix the broken requests

Use the status, headers, and body to diagnose and fix each failing request.

Each request below fails, or doesn't do what its description says. Your job is to find out why and fix it, by editing the cell.

Follow the same steps each time:

  1. Read the status code. Is it the client or the server that needs to change?
  2. Read the body. Does it explain the problem?
  3. Read the headers. Do they offer a hint?
  4. Change one thing, and run the request again.

Some of these requests create contacts, so delete your contacts at the end.

1. Read a contact

This should return the contact with id 123.

2. Create a contact

This should create a contact.

3. Create another contact

This should also create a contact. The headers are correct.

4. Create a third contact

There's one small typing mistake in this one.

5. Update a contact

This should change the name of a contact you created. Replace 128 with your contact's id.

6. Search for contacts

This should find the contacts named Asha whose mobile numbers start with 88.

This one returns 200, so no error points to the problem. Read the body closely.

7. Get a JSON list

This should return five Fibonacci numbers as JSON.

8. Add two numbers

This should add 3 and 4.

9. Find the odd one out

These two requests ask for a contact that doesn't exist. Which of them can a generic HTTP tool recognize as a failure? Why?

Clean up

Delete the contacts you created. To find them, search by name.

Review

You can now answer these questions. If you can't, go back to the lesson on that topic.

  • What are the parts of a URL? Which part identifies the resource?
  • What are the parts of an HTTP request and of a response?
  • What's the difference between POST and PUT?
  • Why is DELETE idempotent, even though a second DELETE can return 404?
  • What's the difference between 401 and 403? Between 400 and 500?
  • What's the difference between Content-Type and Accept?
  • What does it mean for HTTP to be stateless?

You now know HTTP. In the next chapter, we'll use it to design APIs in the REST style.