You are right, there is a lot of confusion. Experts typically refer to 'true' REST APIs as HATEOAS or hypermedia-driven API's to avoid that confusion. Most API's that do call themselves REST api's typically aren't.

So when talking with other engineers about REST apis, it's helpful to first clarify what everyone considers REST and not REST. They're not bad engineers for not knowing, the term 'REST' just kind of got a life of its own , and I would say that HATEOAS is probably a lot more of a niche skill.

I agree with Nicholas Shank's answer that in many cases that the universal thing to do figure out if for example a DELETE works, is to actually issue the DELETE and see if it worked afterwards.

This isn't always helpful though, because many people building API's will want to not show a 'delete' button if it wouldn't work anyway.

So what is a reasonable way to tell a client that DELETE is available? The HTTP standard actually does have an Allow header that you could use to find out what methods work on a given endpoint. To find out what those are, you can issue an OPTIONS request. Not every framework supports this out of the box, but it's a legitimate way to do this.

Another way to tell a client in advance is to embed this information in the resource you are accessing. A couple of examples:

1. link hints is a draft internet standard, that could give these hints in a variety of different places, such as HAL, the HTTP Link header or others. It basically suggests a universal format for this information.
2. If you use something like OpenAPI, you can add to your API specification which methods will and wont work. This can work well for cases where you know a DELETE will simply never work, but it won't help you really well in cases where different users might have different levels of access, and some people can use DELETE and others can't.
3. You can embed this information in your own format, by expressing it as a set of permissions, maybe in a JSON format that your application understands to interpret whether certain actions may be performed.
4. Some HATEAOS formats explicitly embed information about what kind of actions can be taken via actions. A great example is the SIREN format. HAL does not natively have this.

Ultimately a good HATEAOS format will not only return information about the resource and relationships to others, but also will give a set of potential actions that can be taken. Most REST APIs that are HATEAOS tend to not do this, but HTML is the best example of one that does. If there's no link, button or form to do an action, a user can't discover that action.