5 ms·
> It's a list of URLs, which doesn't even indicate what operations they accept. HTTP does not require a particular media type's representation to indicate the
by bmn__ 4y ago
> It's a list of URLs, which doesn't even indicate what operations they accept.
HTTP does not require a particular media type's representation to indicate the allowed methods. What made you think this should be the case? All popular media types I know either contain a partial indication (e.g. forms in HTML), and otherwise a fallback to GET/HEAD as default is implied or specified.
If a client is unsure, there's always the OPTIONS method and the Allow header.
- NonNefarious 4y agoI never said HTTP required that. The point of this discussion is that a remote COMPUTER can't derive the means of using a URL simply because it's listed. What query parameters does it support for a GET operation, for example. This is about APIs, not bog-standard HTTP.
- bmn__ 4y agoOh, I see. The response carries along all the information necessary to continue interacting with the system directly within itself. For example, in HTML there are forms for the purpose you just mentioned, I'll give you two examples: <form method="get" action="search"> <input name="q" type="text"> <form method="get" action="filter"> <select name="items_per_page"> <option>10</option> <option>20</option> <option>50</option> </select> The server instructs what query parameters are supported via the media type and its applicable semantics that are hopefully well defined, which is the case for HTML. Since the client (here: "remote COMPUTER", respectively its user agent) understands the media type, it can successfully uphold its half of the contract and generate the correct resource identifiers and accompanying HTTP requests that are delectable to the server. The same idea applies to other media types.