This is a model developed by Leonard Richardson (expert on RESTful API design) gives us an insights of the principles of the REST Approach into three steps.

This model is primarily a design pattern, you are still free to choose how you design the rest endpoints, but this design gives you a one of proper way of doing so.
Richardson Maturity Model

The inital point where we use HTTP Rest methods as the way to interact with the remote system.

GET /listProducts

We can understand this with a simple example of a E-commerce store. If we want to place an order, we need to find the product we are looking for, so the E-C0mmerce store will create endpoint where we can request for a product list

{
  "items": [
    {
      "id": 1,
      "item_name": "Bike",
      "item_price": "3000"
    },
    {
      "id": 2,
      "item_name": "Smartphone",
      "item_price": "1000"
    },
    {
      "id": 3,
      "item_name": "Watch",
      "item_price": "500"
    }
  ]
}

L1 : Resources

Now as per the RMM Model, In this level we can request the information for the individual resource, we can get additional information for the product

GET /listProducts/1

We can fetch more information of the particular item for ex. Smartphone which help us in deciding whether to buy that or not.

The response might be something like this below,

{
      "id": 2,
      "item_name": "Smartphone",
      "item_price": "1000",
      "item_desc":"smartphone is a cellular telephone with an integrated computer and other features not originally associated with telephones, such as an operating system, web browsing and the ability to run software applications.",
      "item_colors":[
        "Black",
        "White",
        "Blue"
        ]
    }

L2 : HTTP Verbs

This level is more of following the HTTP as closely as possible

GET /placeOrder/1?acct=1234&address=XYZ&gift_pack=true&gift_msg=BestWishes

There is no wrong with the above method as this is work without any problems, but aesthtically it doesn't look good, it clearly shows the immaturity of the designer who does that. Instead placeOrder should be done with post as below. since, this performs/creates something.

POST /placeOrder/1

Request Body:

{
      "acct":1234,
      "address":"XYZ",
      "gift_pack":true,
      "gift_msg":"BestWishes"
    }

Response Body:

{
"id": 2343ecdtcas234dsfsdf
}

L3 : HATEOS / Hypermedia Controls

HATEOS stands for Hypertext As The Engine Of Application State. This will have addtional hypermedia controls of what we can do next, and the URI to modify resource.

POST /placeOrder/1

Request Body:

{
      "acct":1234,
      "address":"XYZ",
      "gift_pack":true,
      "gift_msg":"BestWishes"
    }

Response Body:

{
"id": 2343ecdtcas234dsfsdf,
"change_order": "/changeOrder/2343ecdtcas234dsfsdf"
"fb_shareURL": "https://www.facebook.com/acct_id/share",
"tw_shareURL": "https://www.twitter.com/acct_id/share",
}

This might seems a insignificant information for you, this is the same case for me initially. But you can see the benefits, if the development team uses the URL metioned here dynamically, say "change_order". The future changes doesn't require the downstream systems to manually change this because we are refferring to the value instead.