Subject: Re: [dispatch] Building Blocks for HTTP APIs - next steps

From: Darrel Miller <[email-masked]>
Date: Sun, 2 Aug 2020 03:18:26 +0000

Hi Rob,

There is a sub group within the Linux Foundation GraphQL project that is focused on creating a specification of how GraphQL should be layered on HTTP. https://github.com/graphql/graphql-over-http/blob/master/spec/GraphQLOverHTTP.md

I think the HTTP API Working group could co-ordinate with that group to identify any gaps in HTTP conventions/patterns or guidance that would help with GraphQL layering over HTTP.

>From the perspective of HTTP, GraphQL is media type for the query and one for the schema.  The response is application/json.  GraphQL could definitely make use of the SEARCH method.

I see efforts such as GraphQL, JSON API, OpenAPI, RAML, OData as being “customers” of the work of the HTTP API working group.  I don’t know if the charter needs to reflect that.

Darrel

From: Rob Sayre<mailto:[email-masked]>
Sent: July 31, 2020 8:19 PM
To: Mark Nottingham<mailto:[email-masked]>
Cc: DISPATCH WG<mailto:[email-masked]>
Subject: Re: [dispatch] Building Blocks for HTTP APIs - next steps

On Fri, Jul 31, 2020 at 5:03 AM Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
Hi everyone,

After some tweaks resulting from the meeting discussion, I think this charter proposal is ready to go to the ADs. Any last comments?

It might be good to address the value this effort will add in addition to things like GraphQL:

https://thenewstack.io/graphql-gets-its-own-foundation/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fthenewstack.io%2Fgraphql-gets-its-own-foundation%2F&data=02%7C01%7Cdarrel.miller%40microsoft.com%7Cfb5e0ed0bd52443c5f8708d835b08cb3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318379733280445&sdata=ilTu%2F%2F1fGtPJS1fVC%2BoVZqW5jd0MxbcKNaxXyUAiqEU%3D&reserved=0>

thanks,
Rob

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Aug 2020 14:36:56 +1000

> On 1 Aug 2020, at 3:46 am, Wenbo Zhu <wenboz=[email-masked]> wrote:
> 
> > HTTP is often for not only Web browsing, but also machine-to-machine communication ....
> 
> Are we talking about "HTTP as a transport" here, which includes e.g. "apis" (external consumption, e.g.. ws), micro-services (rpcs), messaging frameworks, non-browser-clients etc etc ... ?

Yes. The charter frames the work by starting with 'HTTP is often for not only Web browsing, but also machine-to-machine communication'...

> 
> > broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API team
> 
> This seems to suggest we are only interested in use cases when HTTP is used as the transport for public API end-points

I think that's a primary interest; this being the IETF, we're interested in the Internet, and if private networks can get benefit / leverage from what we do, that's great, but we shouldn't be constrained by them.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Rob Sayre <[email-masked]>
Date: Tue, 4 Aug 2020 22:09:48 -0700

On Sat, Aug 1, 2020 at 8:18 PM Darrel Miller <[email-masked]>
wrote:

> Hi Rob,
>
>
>
> There is a sub group within the Linux Foundation GraphQL project that is
> focused on creating a specification of how GraphQL should be layered on
> HTTP.
> https://github.com/graphql/graphql-over-http/blob/master/spec/GraphQLOverHTTP.md
>
>
>
> I think the HTTP API Working group could co-ordinate with that group to
> identify any gaps in HTTP conventions/patterns or guidance that would help
> with GraphQL layering over HTTP.
>
>
>
> From the perspective of HTTP, GraphQL is media type for the query and one
> for the schema.  The response is application/json...
>

I don't agree. The reference implementations of GraphQL expect
application/json, but higher-traffic services do not tend to use that
format. See: https://spec.graphql.org/June2018/#sec-Serialization-Format

While this is not an objection, I think the WG might want to avoid defining
APIs in terms of links and JSON, when that is becoming a less common tactic.

thanks,
Rob