Re: Registration Request for the respond-for HTTP preference

Irakli, thank you for this submission. I am quite interested in giving HTTP functionality from GraphQL.

In your approach, the server and client agree on a set of "bundles" of data to transmit, such as `minimal` or `full_representation`. This is cool! But I am curious why you want to specify which bundle to request using the `Prefer` header, rather than just in the URL?

For instance, what is the advantage of doing this:

  Get /users/123 HTTP/1.1
  Host: api.example.org
  Content-Type: application/json  
  Prefer: return=minimal
  Vary: Prefer,Accept,Accept-Encoding

Rather than this:

  Get /users/123?subset=minimal HTTP/1.1
  Host: api.example.org
  Content-Type: application/json  
  Vary: Prefer,Accept,Accept-Encoding
?

The reference blog post suggests that the problem with embedding the bundle-id in the URL is that it couples the client with the server. However, this is the case with specifying the bundle-id in the Prefer header as well.

> On Apr 27, 2020, at 7:06 PM, irakli <irakli@gmail.com> wrote:
> 
>    o  Preference: respond-for
> 
>    o  Value: any alpha-numeric value. Dashes are also allowed.
> 
>    o  Optional Parameters: None
> 
>    o  Description: Expanded version of the "return" preference that 
> allows clients to hint to the server the use-case for the response.
> This allows batching response variations by common use-cases. The goal
> is similar to GraphQL: letting client choose which data it needs, but
> is significantly more light-weight and can allow all that client needs
> in a very wide variety of cases, without resorting to heavier and 
> potentially riskier GraphQL approach. For instance, for a blog post
> a client may request "respond-for: teaser" or "respond-for: full-post"  
> 
>    o  Reference: https://www.freshblurbs.com/blog/2015/06/25/api-representations-prefer.html <https://www.freshblurbs.com/blog/2015/06/25/api-representations-prefer.html>
> 
>    o  Notes: We have used this approach successfully at a number of 
> companies over the years but would like to standardize the preference
> rather than using an unregistered preference, or using the "return" 
> preference with values that are non-standard.
> 
> 
> Thank you!
> 
> Irakli Nadareishvili