Quoting this article – The Other key differences: gRPC vs. REST section (client server coupling):

Client-server coupling

REST is loosely coupled, which means the client and the server do not
need to know anything about the other’s implementation. This loose
coupling makes the API easier to evolve over time. This is because a
change in server definitions does not necessarily require a code
change in the client.

gRPC is tightly coupled, which means the client and server must have
access to the same proto file. Any updates to the file require updates
in both the server and the client.

Every project that uses RESTful APIs I have worked so far – has a shared contract between client and server. For example:

Client code (in C#):

  var jsonSerializedObj = JsonConvert.Serialize(new MyRequestType { ... });
  var response = await httpClient.PostAsync(".../myPostMethod1", jsonSerializedObj);
  //response's type is part of the contract between client and server for this post method

Server code (in C#):

[HttpPost]
async Task<MyResponseType> MyPostMethod1(MyRequestType request)
{
   ...
   return new MyResponseType {...};
}

(leaving aside technical nuances/syntax errors)

1. At first, MyRequestType and MyResponseType constitute a shared contract for this specific REST api method. Meaning changing any of them impacts both client and server.
2. If contracts are serialized/deserialized as json objects and sent/returned this way – I can see how, this way, adding new object properties does not break existing versions (json deserializing will ignore properties not existent in current type) – but still, in the new version – both client and server has to know about the change in order to benefit from it.

Am I wrong ? If what I said is right/commonplace, how/where is the REST decoupling the article talks about ?