4 ms·

There is currently no way to determine whether there's, for example, an application/json representation of a URL that returns text/html by default. OPTIONS and

There is currently no way to determine whether there's, for example, an application/json representation of a URL that returns text/html by default. OPTIONS and PROPFIND don't get it. There should be an HTTP method (or a .well-known url path prefix) to query and list every Content-Type available for a given URL. From https://x.com/westurner/status/1111000098174050304 https://x.com/westurner/status/1111000098174050304 : > So, given the current web standards, it's still not possible to determine what's lurking behind a URL given the correct headers? Seems like that could've been the first task for structured data on the internet

tarasglek 2y ago
Yeah no way to ask for openapi schema definition.
- westurner 2y ago
  https://schema.org/WebAPI https://schema.org/WebAPI https://github.com/schemaorg/schemaorg/issues/1423#issuecomment-667586962 https://github.com/schemaorg/schemaorg/issues/1423#issuecomm... : > Examples of how to represent GraphQL, SPARQL, LDP, and SOLID APIs [as properties of one or more rdfs:subClassOf schema:WebAPI (as RDFa in HTML or JSON-LD)]
treve 2y ago
Servers can return something like: Link: </foo>; rel="alternate" type="application/json" You could return multiple of these as a response to a HEAD request for example. You could also use the Accept header in response to a HTTP OPTIONS request, or as part of a 415 error response. Accept: application/json, text/html https://httpwg.org/specs/rfc9110.html#field.accept https://httpwg.org/specs/rfc9110.html#field.accept (yes Accept can be used in responses) .well-known is not a good place for this kind of thing. That discovery mechanism should only be used in situations where only a domainname is known, and a feature or endpoint needs to be discovered for a full domain. In most cases you want a link. The building blocks for most of this stuff is certainly there. There's a lot of wheels being reinvented all the time.
- westurner 2y ago
  > https://httpwg.org/specs/rfc9110.html#field.accept https://httpwg.org/specs/rfc9110.html#field.accept (yes Accept can be used in responses) I think that would solve. HTTP servers SHOULD send one or more Accept: {content_type} HTTP headers in the HTTP Response to an HTTP OPTIONS Request in order to indicate which content types can be requested from that path.
  - westurner 2y ago
    IDK where that should be added though? Maybe REST and W3C LDP and similar The OpenAPI docs could suggest same

tarasglek 2y ago

Yeah no way to ask for openapi schema definition.

westurner 2y ago
https://schema.org/WebAPI https://schema.org/WebAPI https://github.com/schemaorg/schemaorg/issues/1423#issuecomment-667586962 https://github.com/schemaorg/schemaorg/issues/1423#issuecomm... : > Examples of how to represent GraphQL, SPARQL, LDP, and SOLID APIs [as properties of one or more rdfs:subClassOf schema:WebAPI (as RDFa in HTML or JSON-LD)]

treve 2y ago

Servers can return something like: Link: </foo>; rel="alternate" type="application/json" You could return multiple of these as a response to a HEAD request for example. You could also use the Accept header in response to a HTTP OPTIONS request, or as part of a 415 error response. Accept: application/json, text/html https://httpwg.org/specs/rfc9110.html#field.accept https://httpwg.org/specs/rfc9110.html#field.accept (yes Accept can be used in responses) .well-known is not a good place for this kind of thing. That discovery mechanism should only be used in situations where only a domainname is known, and a feature or endpoint needs to be discovered for a full domain. In most cases you want a link. The building blocks for most of this stuff is certainly there. There's a lot of wheels being reinvented all the time.

westurner 2y ago
> https://httpwg.org/specs/rfc9110.html#field.accept https://httpwg.org/specs/rfc9110.html#field.accept (yes Accept can be used in responses) I think that would solve. HTTP servers SHOULD send one or more Accept: {content_type} HTTP headers in the HTTP Response to an HTTP OPTIONS Request in order to indicate which content types can be requested from that path.
- westurner 2y ago
  IDK where that should be added though? Maybe REST and W3C LDP and similar The OpenAPI docs could suggest same