Under the architecture I describe, no, clients and servers do not couple to one another. The client and server couple to a data interchange format.
> contracts define types
Yes, the interchange format defines the types for the interchange. But a string can be represented as an enumeration or a float or an integer or a boolean. The type of the data is dependent on context.
> REST focuses almost exclusively on types
In a sense yes, but it also focuses on decoupling clients and servers. The types are really more of an implementation detail. The type of interchange can be XML, HTML, JSON, bytes, text, etc. The fields in a JSON document can all be strings for the purposes of interchange but may be parsed to integers and floats for the purposes of rendering the data to the user. The server may parse those fields differently.
Its not relevant to the client or the server how the other chooses to interpret the data. All that matters is that the interchange format is maintained.
Under the architecture I describe, no, clients and servers do not couple to one another. The client and server couple to a data interchange format.
> contracts define types
Yes, the interchange format defines the types for the interchange. But a string can be represented as an enumeration or a float or an integer or a boolean. The type of the data is dependent on context.
> REST focuses almost exclusively on types
In a sense yes, but it also focuses on decoupling clients and servers. The types are really more of an implementation detail. The type of interchange can be XML, HTML, JSON, bytes, text, etc. The fields in a JSON document can all be strings for the purposes of interchange but may be parsed to integers and floats for the purposes of rendering the data to the user. The server may parse those fields differently.
Its not relevant to the client or the server how the other chooses to interpret the data. All that matters is that the interchange format is maintained.