I think you're commenting on GraphQL vs REST itself, and I don't disagree with what you're saying. Your comment, however, seems disconnected from what I attempted to express in the comment that you replied to. My comment was probably not clear, so I'll try to explain:

My comment is about the tooling and its effects on my workflow, which is mostly orthogonal to static vs dynamic typing. Specifically, I'm expressing a preference for simple tools over special-purpose tools. It was very common for me to test REST APIs with curl and share curl commands on team chat that others could copy/paste to reproduce something. SOAP and GraphQL tend to encourage the use of specialized tools, which adds friction to this kind of workflow (which happens on a daily basis). In fact, what I've seen since adopting GraphQL is people sharing screenshots from their IDE. It's in that respect that working with GraphQL reminds me a lot of working with SOAP.

That said, I don't think GraphQL is as bad as SOAP in this respect. I can still use curl to test out GraphQL APIs. It's just a bit awkward and takes longer to construct the command. I don't remember ever doing that with SOAP, but it's also been a long time since I've used a SOAP API.

Returning to your analogy to static vs dynamic typing, I completely agree about static typing helping manage complexity [1], but it doesn't dictate which tool I use. I can write C programs in vim or I can write them in XCode, Visual Studio, or some other IDE. I prefer vim. GraphQL and SOAP feel like using a language that almost forces me to use an IDE.

[1] Static vs dynamic typing isn't the whole story, though. There's also strong vs weak typing. Haskell and C are both statically typed, but Haskell is strongly typed whereas C is usually considered weakly typed. Strong typing helps manage complexity compared to weak typing.

It's a real game-changer.