Unknown Challenger ID

To view your challenges status in multi-user mode, make sure you have registered as a challenger using a `POST` request to `/challenger` and are including an `X-CHALLENGER` header in all your requests.

Then view the challenges in the GUI by visiting `/gui/challenges/{GUID}`, where `{GUID}` is the value in the `X-CHALLENGER` header.

You can find more information about this on the Multi User Help Page

Getting Started

If you want to track your challenge progress, in multi-user mode then you need to solve the challenges in this section to generate a unique ID that we can associate your progress with.

IDChallengeDoneDescription
01POST /challenger (201)false

Issue a POST request on the `/challenger` end point, with no body, to create a new challenger session. Use the generated X-CHALLENGER header in future requests to track challenge completion.


Hints
  • In multi-user mode, you need to create an X-CHALLENGER Session first Learn More
Solution

First Real Challenge

For your first challenge, get the list of challenges. You'll be able to use this to see your progress in your API Client, as well as using the GUI.

IDChallengeDoneDescription
02GET /challenges (200)false

Issue a GET request on the `/challenges` end point


Solution

GET Challenges

To retrieve, or read information from an API we issue GET requests. This section has a bunch of GET request challenges to try out.

IDChallengeDoneDescription
03GET /todos (200)false

Issue a GET request on the `/todos` end point


Solution
04GET /todo (404) not pluralfalse

Issue a GET request on the `/todo` end point should 404 because nouns should be plural


Solution
05GET /todos/{id} (200)false

Issue a GET request on the `/todos/{id}` end point to return a specific todo


Hints
  • Make sure you don't use {id} in the url, replace that with the id of a todo e.g. /todos/1
Solution
06GET /todos/{id} (404)false

Issue a GET request on the `/todos/{id}` end point for a todo that does not exist


Hints
  • Make sure you don't use {id} in the url, replace that with the id of a todo e.g. /todos/1
  • Make sure the id is an integer e.g. /todos/1
  • Make sure you are using the /todos end point e.g. /todos/1
Solution

HEAD Challenges

A HEAD request, is like a GET request, but only returns the headers and status code.

IDChallengeDoneDescription
07HEAD /todos (200)false

Issue a HEAD request on the `/todos` end point


Solution

Creation Challenges with POST

A POST request can be used to create and update data, these challenges are to 'create' data. As a Hint, if you are not sure what the message body should be, try copying in the response from the assocated GET request, and amending it.

IDChallengeDoneDescription
08POST /todos (201)false

Issue a POST request to successfully create a todo


Solution
09GET /todos (200) ?filterfalse

Issue a GET request on the `/todos` end point with a query filter to get only todos which are 'done'. There must exist both 'done' and 'not done' todos, to pass this challenge.


Hints
  • A query filter is a URL parameter using the field name and a value
  • A URL parameter is added to the end of a url with a ? e.g. /todos?id=1
  • To filter on 'done' we use the 'doneStatus' field ? e.g. ?doneStatus=true
  • Make sure there are todos which are done, and not yet done
Solution
10POST /todos (400) doneStatusfalse

Issue a POST request to create a todo but fail validation on the `doneStatus` field


Solution

Update Challenges with POST

Use a POST request to amend something that already exists. These are 'partial' content updates so you useually don't need to have all details of the entity in the request, e.g. you could just update a title, or a description, or a status

IDChallengeDoneDescription
11POST /todos/{id} (200)false

Issue a POST request to successfully update a todo


Hints
  • Make sure you don't use {id} in the url, replace that with the id of a todo e.g. /todos/1
Solution

DELETE Challenges

Use a DELETE request to delete an entity. Since this is an extreme request, normall you have to be logged in or authenticated, but we wanted to make life easier for you so we cover authentication later. Anyone can delete To Do items without authentication in this system.

IDChallengeDoneDescription
12DELETE /todos/{id} (200)false

Issue a DELETE request to successfully delete a todo


Hints
  • Make sure you don't use {id} in the url, replace that with the id of a todo e.g. /todos/1
  • Make sure a todo with the id exists prior to issuing the request
  • Check it was deleted by issuing a GET or HEAD on the /todos/{id}
Solution

OPTIONS Challenges

Use an OPTIONS verb and check the `Allow` header, this will show you what verbs are allowed to be used on an endpoint. When you test APIs it is worth checking to see if all the verbs listed are allowed or not.

IDChallengeDoneDescription
13OPTIONS /todos (200)false

Issue an OPTIONS request on the `/todos` end point. You might want to manually check the 'Allow' header in the response is as expected.


Solution

Accept Challenges

The `Accept` header, tells the server what format you want the response to be in. By changing the `Accept` header you can specify JSON or XML.

IDChallengeDoneDescription
14GET /todos (200) XMLfalse

Issue a GET request on the `/todos` end point with an `Accept` header of `application/xml` to receive results in XML format


Solution
15GET /todos (200) JSONfalse

Issue a GET request on the `/todos` end point with an `Accept` header of `application/json` to receive results in JSON format


Solution
16GET /todos (200) ANYfalse

Issue a GET request on the `/todos` end point with an `Accept` header of `*/*` to receive results in default JSON format


Solution
17GET /todos (200) XML preffalse

Issue a GET request on the `/todos` end point with an `Accept` header of `application/xml, application/json` to receive results in the preferred XML format


Solution
18GET /todos (200) no acceptfalse

Issue a GET request on the `/todos` end point with no `Accept` header present in the message to receive results in default JSON format


Solution
19GET /todos (406)false

Issue a GET request on the `/todos` end point with an `Accept` header `application/gzip` to receive 406 'NOT ACCEPTABLE' status code


Solution

Content-Type Challenges

The `Content-Type` header, tells the server what format type your 'body' content is, e.g. are you sending XML or JSON.

IDChallengeDoneDescription
20POST /todos XMLfalse

Issue a POST request on the `/todos` end point to create a todo using Content-Type `application/xml`, and Accepting only XML ie. Accept header of `application/xml`


Solution
21POST /todos JSONfalse

Issue a POST request on the `/todos` end point to create a todo using Content-Type `application/json`, and Accepting only JSON ie. Accept header of `application/json`


Solution
22POST /todos (415)false

Issue a POST request on the `/todos` end point with an unsupported content type to generate a 415 status code


Solution

Mix Accept and Content-Type Challenges

We can mix the `Accept` and `Content-Type` headers so that we can send JSON but receive XML. These challenges encourage you to explore some combinations.

IDChallengeDoneDescription
23POST /todos XML to JSONfalse

Issue a POST request on the `/todos` end point to create a todo using Content-Type `application/xml` but Accept `application/json`


Solution
24POST /todos JSON to XMLfalse

Issue a POST request on the `/todos` end point to create a todo using Content-Type `application/json` but Accept `application/xml`


Solution

Status Code Challenges

Status-codes are essential to understand, so we created some challenges that help you trigger more status codes. Remember to review httpstatuses.com to learn what the status codes mean.

IDChallengeDoneDescription
25DELETE /heartbeat (405)false

Issue a DELETE request on the `/heartbeat` end point and receive 405 (Method Not Allowed)


Solution
26PATCH /heartbeat (500)false

Issue a PATCH request on the `/heartbeat` end point and receive 500 (internal server error)


Solution
27TRACE /heartbeat (501)false

Issue a TRACE request on the `/heartbeat` end point and receive 501 (Not Implemented)


Solution
28GET /heartbeat (204)false

Issue a GET request on the `/heartbeat` end point and receive 204 when server is running


Solution

Authentication Challenges

Authentication is telling the system who you are. In multi-user mode you are already doing that with the X-CHALLENGER header, but we have added an extra level of security on the /secret section. So first Authenticate with Basic Authentication to find out the token to use for authorisation for later challenges.

IDChallengeDoneDescription
29POST /secret/token (401)false

Issue a POST request on the `/secret/token` end point and receive 401 when Basic auth username/password is not admin/password


Hints
  • Remember to add your X-CHALLENGER guid header
Solution
30POST /secret/token (201)false

Issue a POST request on the `/secret/token` end point and receive 201 when Basic auth username/password is admin/password


Hints
  • Remember to add your X-CHALLENGER guid header
Solution

Authorization Challenges

Once the system knows who you are, authorization is if you have the correct level of access. In these challenges the authorization is granted using a custom API header X-AUTH-TOKEN or using a Bearer Authorization header.

IDChallengeDoneDescription
31GET /secret/note (403)false

Issue a GET request on the `/secret/note` end point and receive 403 when X-AUTH-TOKEN does not match a valid token


Hints
  • Remember to add your X-CHALLENGER guid header
Solution
32GET /secret/note (401)false

Issue a GET request on the `/secret/note` end point and receive 401 when no X-AUTH-TOKEN header present


Hints
  • Remember to add your X-CHALLENGER guid header
Solution
33GET /secret/note (200)false

Issue a GET request on the `/secret/note` end point receive 200 when valid X-AUTH-TOKEN used - response body should contain the note


Hints
  • Remember to add your X-CHALLENGER guid header
Solution
34POST /secret/note (200)false

Issue a POST request on the `/secret/note` end point with a note payload e.g. {"note":"my note"} and receive 200 when valid X-AUTH-TOKEN used. Note is maximum length 100 chars and will be truncated when stored.


Hints
  • Remember to add your X-CHALLENGER guid header
Solution
35POST /secret/note (401)false

Issue a POST request on the `/secret/note` end point with a note payload {"note":"my note"} and receive 401 when no X-AUTH-TOKEN present


Hints
  • Remember to add your X-CHALLENGER guid header
Solution
36POST /secret/note (403)false

Issue a POST request on the `/secret/note` end point with a note payload {"note":"my note"} and receive 403 when X-AUTH-TOKEN does not match a valid token


Hints
  • Remember to add your X-CHALLENGER guid header
Solution
37GET /secret/note (Bearer)false

Issue a GET request on the `/secret/note` end point receive 200 when using the X-AUTH-TOKEN value as an Authorization Bearer token - response body should contain the note


Hints
  • Remember to add your X-CHALLENGER guid header
Solution
38POST /secret/note (Bearer)false

Issue a POST request on the `/secret/note` end point with a note payload e.g. {"note":"my note"} and receive 200 when valid X-AUTH-TOKEN value used as an Authorization Bearer token. Status code 200 received. Note is maximum length 100 chars and will be truncated when stored.


Hints
  • Remember to add your X-CHALLENGER guid header
Solution

Miscellaneous Challenges

We left these challenges to the end because they seemed fun, but... different.

IDChallengeDoneDescription
39DELETE /todos/{id} (200) allfalse

Issue a DELETE request to successfully delete the last todo in system so that there are no more todos in the system


Hints
  • After deleting the last todo, there will be no todos left in the application
  • Make sure you don't use {id} in the url, replace that with the id of a todo e.g. /todos/1
  • You have to delete all the todo items in the system to complete this challenge