How to tell if a server implements this spec? about graphql-over-http HOT 9 CLOSED

@michaelstaib I agree that these "feature opt-ins" are going to be important, and that's what I was getting at too. The easiest approach is likely to allow a list of fully qualified spec URIs as opposed to a single URI.

from graphql-over-http.

👍 The spec identifier would need to be parsable, and ideally able to communicate which features it supports (for example, sending via POST only, multipart, websocket, etc).

from graphql-over-http.

request to the URL that claims to be a GraphQL HTTP

Do you mean root address like http://example.org ?

Response comes with a Header like X-GRAPHQL-HTTP that includes a link to the published spec

Do you mean link to download SDL document from or http://example.org/graphql link to send requests?

from graphql-over-http.

@sungam3r

Do you mean root address like http://example.org ?

The route where that handles the GraphQL requests since the root address could be handled by a completely different server. So if your GraphQL endpoint is http://foo.com/graphql than this is where you have to issue the options request.

Do you mean link to download SDL document from or http://example.org/graphql link to send requests?

No, it is more like the idea with the custom scalars where you would point to the specification document of the DateTime scalar for instance.

For this particular case we would then point to the URL where the GraphQL HTTP Spec is published.

from graphql-over-http.

@mike-marcacci

The spec identifier would need to be parsable, and ideally able to communicate which features it supports (for example, sending via POST only, multipart, websocket, etc).

It sounds to be basically the same like with the scalar. It does not have to be parsable in the sense that you would extract from it various information. I think it is enough if it is just the URL to the specific spec version.

But I mean, it depends where the HTTP spec really is going. Do we want to create a minimal spec that describes the minimal necessary to communicate with a GraphQL server or are we heading into things like @defer where we also want to describe how we would do result patches over http.

Personally I think GraphQL over HTTP should consist of a view specs :)

@leebyron

In RFC 6648 the recommendation to prefix application-specific headers with X- was retracted. It is mentioned in RFC 2616 as a permanently-reserved prefix for implementors, but is deprecated due to the complexities of migrating prefixed headers to standardized ones.

https://tools.ietf.org/html/rfc6648

from graphql-over-http.

@michaelstaib Thank you, I realized that it's about HTTP spec support.

from graphql-over-http.

I am just wondering if we really should have a way to ask the server for the http features that the server supports.

The suggestions that we ask the server just if it supports the spec might be not enough.

I remember @robzhu raising the idea for asking a GraphQL server for what features it does support from the core spec. While I do not see that with the core spec I think it is an interesting concept for the HTTP spec.

Things like request batching, operation batching, WebSocket subscriptions, SignalR subscriptions and so on are features that are closely related to the transport layer and I think we cannot expect that every server implements all of those. I think a capability like that would lower the burden to implement the HTTP spec while also allowing to standardize things like batching and subscriptions and so on.

from graphql-over-http.

I am totally in support of this but in the manner @mike-marcacci suggests.

from graphql-over-http.

I hope that the server responding to application/graphql+json should be sufficient to indicate it implements the spec. Let's leave feature discovery for a different topic (which may well include an OPTIONS request).

from graphql-over-http.