TLDR: It chooses from the options provided by the server.

It doesn't really know the "resources", "methods" nor formats involved, the same way you don't know what resources you're manipulating when you order on amazon. When was the last time you cared what URIs that process goes through, or what HTTP methods are involved?

Long answer: I find your question refreshingly insightful actually. What you've discovered is that there are two completely opposing interpretations of what REST is. Confusingly enough, both think they are the thing that Roy Fielding originally described.

So the colloquial usage of "REST", is anything that is JSON over HTTP. That's it. Most articles, examples, tutorials, even software, even those that mention HATEOAS are in this camp.

These usually think URIs matter, or talking about HTTP Methods, or using Swagger/OpenAPI. These are all just JSON over HTTP, mostly RPC-like constructs, where the whole process, URIs and what happens when is hardcoded into the client.

The other interpretation tries to closely follow the original idea of Roy Fielding, which is basically how the Web works. Not HTTP, but HTML. As in, some hypertext format, with links and forms, each page representing some state in a workflow for the user. Here the workflow is not hardcoded into the client (the browser), but the user chooses by manipulating the currently presented representation (the web page).

So machine-readable REST should obviously behave the same. The client doesn't really know the individual resources at all, instead it knows the hypermedia formats involved! It knows how to follow a link, how to submit a form. That form may or may not describe technical things like HTTP Methods (just like a HTML Form does), but that is irrelevant to the client. The representation tells the client what it can do. At all times. The client doesn't suddenly know how to construct a specific json format for a specific URI. That would be completely preposterous.

HTH.

TLDR: It chooses from the options provided by the server.

It doesn't really know the "resources", "methods" nor formats involved, the same way you don't know what resources you're manipulating when you order on amazon. When was the last time you cared what URIs that process goes through, or what HTTP methods are involved?

Long answer: I find your question refreshingly insightful actually. What you've discovered is that there are two completely opposing interpretations of what REST is. Confusingly enough, both think they are the thing that Roy Fielding originally described.

So the colloquial usage of "REST", is anything that is JSON over HTTP. That's it. Most articles, examples, tutorials, even software, even those that mention HATEOAS are in this camp.

These usually think URIs matter, or talking about HTTP Methods, or using Swagger/OpenAPI. These are all just JSON over HTTP, mostly RPC-like constructs, where the whole process, URIs and what happens when is hardcoded into the client.

The other interpretation tries to closely follow the original idea of Roy Fielding, which is basically how the Web works. Not HTTP, but HTML. As in, some hypertext format, with links and forms, each page representing some state in a workflow for the user. Here the workflow is not hardcoded into the client (the browser), but the user chooses by manipulating the currently presented representation (the web page).

So machine-readable REST should obviously behave the same. The client doesn't really know the individual resources at all, instead it knows the hypermedia formats involved! It knows how to follow a link, how to submit a form. That form may or may not describe technical things like HTTP Methods (just like a HTML Form does), but that is irrelevant to the client. The representation tells the client what it can do. At all times. The client doesn't suddenly know how to construct a specific json format for a specific URI. That would be completely preposterous.

HTH.

Update to the last paragraph: When I say it knows the hypermedia formats involved, I don't just mean it knows that it is json. It must know what it means too. That it is an order page for example. One crucial difference between REST for humans and machines is, that humans interpret based on text on the page, while machines interpret based on media-types, at least for now. This is why you see custom media-types, or 100, proposed. That is not necessarily needed, but it is a valid option.