> whereas a statically typed API statically checks and guarantees the contract

I didn't work much with static typed languages lately, so I'm really puzzled by your comment. If I expect an int in the age field of a JSON response and the server suddenly sends me a string, maybe with value "NaN", how do you check for that at compile time? I expect the program to either crash or manage the error at run time (try/catch, die-and-restart a-la-Erlang, etc)

Maybe JSON doesn't count as "statically typed API", but how many of them do common Internet services expose to the public? And how to we make sure that the server or any in between proxy doesn't misbehave and violates the contract?

There are different kinds of APIs. You seem to be talking about inherently dynamic ones, such as your JSON blob example. Of course you cannot statically guarantee their contents, which is why statically typed JSON layers provide ways of asserting a schema. Using such schema checkers is best practice even in dynamically typed languages.

Either way, you need to handle such failures, both in statically and in dynamically type-checked languages. The only difference is whether the handling happens explicitly throughout your code or automagically by an API that gives you back a well-behaved object. And both of these ways are possible in both static and dynamic languages (but static languages tend to go for the latter, whereas dynamic languages tend to make you do the former).

The way this works is, when you say “please turn this JSON string into a data structure”, it’s a fallible operation. So, if that JSON string does not have what you expect, the serialization operation will fail. You can “check at compile time” by the system ensuring that you handle the success and failure cases. Additionally, it means that if you have an instance of that data structure, it is always valid; it is checked (at runtime) upon creation.

Does that make sense? I can show you some code if you’d like.

There's nothing stopping a dynamically typed system from using something like grpc or graphql that can check for missing fields. Or something like json schema to check for missing fields in a lot of those scenarios. A type system doesn't necessarily catch missing fields, but a communication framework of some kind, does.

I entirely agree, see my orthogonal comment reply.