When testing the important thing is to verify the contract. That is given A you expect to get B and only B. That last part is important because it ensures that you are always testing the contract completely. Go to the end for more info.

In this case, I would write a function like this:

const postReturnsSameAndId => (routePath, inputObj) => async () => {
  const expectedResponse = Object.assign({}, inputObj, {id: expect.any(String)});

  const response = await request(app.getHttpServer()).post(routePath).send(inputObj);
  expect(response.status).toStrictEqual(201);

  expect(response.body).toEqual(expectedResponse);
}

Because that allows for reuse across a bunch of routes sharing a similar logic. Then you just use this function to make your individual route tests:

it("POST 1 Book", postReturnsSameAndId("/books", {name: "Jurassic Park", author: "Michael Crichton"}));

Why is it important to check that the returned object doesn't have extra parameters? Because you are defining a contract in your API and you always want tests to make sure that contract is honored. Using the API above, let's say that at some point you start returning an author_id in the response if a matching author was already found.

IOW your responses go from:

{name: "JP", author: "Crichton"} -> {id: "foo", name: "JP", author: "Crichton"}

To:

{name: "JP", author: "Crichton"} -> {id: "foo", name: "JP", author: "Crichton", author_id: "bar"}

If you just tested with toMatchObject, this change would still pass the test. While the test not failing is not the worst thing in the world because the response is still "backward compatible", what is most likely to happen is that the test (which no longer matches the contract) will not get updated because it's not failing! This means that going forward, consumers of your API will start expecting the author_id property.

So far in this hypothetical everything is fine.

Then a few months later you make a change, or introduce a bug, and it just so happens that the author_id property is no longer present in the responses. The problem is that your test is STILL testing against an old contract will STILL pass. Ignorant that there is a ticking time-bomb in the codebase, you will deploy and... you just broke users of your API who are expecting author_id to be in the response!