REST (like "object-oriented programming") is an ambiguous term that might refer to a reasonable and usable subset of behavior, or it might refer to a more extensive hypermedia-style design pattern.
REST, in the hypermedia sense, and in the sense of "the design principles behind HTTP in the first place", is a good way for a server to expose data to an intelligent human-guided client (i.e. a web browser). It doesn't do a lot for the API case, but it does a little and there's enough tooling to get you the rest of the way.
I usually don't even think of REST API's as RESTful. I think of them as RPCs that exchange JSON, except you define the RPC endpoint as an HTTP verb/URL pattern tuple, accept and treat as a contract the standards behind different verbs, use response codes for out-of-band metadata, and piggyback on all the tooling and infrastructure that people already built around serving HTTP to web browsers in the first place. If you want to strongly type your RPC, you can use OpenAPI. If you want to define your RPC ahead of time and then generate server and/or client code from a definition, you can use Swagger Codegen. There's enough adequate tooling that you don't necessarily need to resort to an actual RPC protocol, but that doesn't mean your REST API actually has to be RESTful in any meaningful way, or even that it should be.