Subject: [dispatch] HTTP profile negotiation - httpapi?

From: Kirsty P <[email-masked]>
Date: Wed, 10 Mar 2021 19:53:44 +0000

Dispatchers,

After Ruben's presentation to the session on Monday, the outcome for HTTP profile negotiation (draft: https://datatracker.ietf.org/doc/draft-svensson-profiled-representations/) was: to have more discussion on lists to confirm where it should go, with early indications suggesting it's destined for httpapi.

Therefore, let's have that discussion...

Kirsty

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: "Lars G. Svensson" <[email-masked]>
Date: Thu, 11 Mar 2021 12:36:02 +0100

On Mittwoch, 10. März 2021 um 20:53 Uhr, "Kirsty P" <[email-masked]> wrote:
 
> After Ruben's presentation to the session on Monday, the outcome for HTTP profile negotiation
> (draft: https://datatracker.ietf.org/doc/draft-svensson-profiled-representations/) was: to have
> more discussion on lists to confirm where it should go, with early indications suggesting it's
> destined for httpapi.
 
> Therefore, let's have that discussion...

Thank you Kirsty for moving this forward.

Within the W3C Data Exchange WG [1] there are activities building on this proposal including some implementation work [2]. Even if this does not help us in choosing the appropriate WG, it does show that the proposal solves a problem that some communities have.

[1] https://www.w3.org/2017/dxwg/
[2] https://w3c.github.io/dx-connegp/connegp-implementation-report/

Best,

Lars

---

From: Darrel Miller <[email-masked]>
Date: Sat, 20 Mar 2021 21:43:22 +0000

First off, as a co-chair of the HTTPAPI working group, apologies for not being present in the dispatch meeting.

Speaking as an individual, my concern with this proposal is that while I do understand the value that this proposal brings, my experience is that the vast majority of API practitioners do not care.   Trying to sell the value of self-descriptive HTTP responses has mostly fallen on deaf ears for the last 15 years, and I don't see anything that is changing that sentiment.

The notion of using profile to further qualify a media type is something that a number of people in the industry have tried to promote for years and it has gained very little traction.  I don't believe standardization of negotiation and discovery will change that.

Fundamentally, most API practitioners don't see the negative system impact of coupling a resource identifier with response semantics.  When they call GET /customer  and they get application/json back they don't see a problem with assuming the properties of that payload contain customer information.  Sure, it violates REST's self-descriptive constraint, but try convincing an API developer to care.  I spent many years trying unsuccessfully.  The popularity of API description formats is evidence that devs don't care about the coupling introduced by connecting response semantics with resource identifiers.

In the dispatch meeting, the assertion was made that profiles enable versioning.  But so does changing the resource identifier, which is the common practice today.

I have zero technical objections to the principles presented in the RFC, in fact I support them.  But I strongly believe that history has demonstrated that they will not get mainstream adoption and hence I am reluctant to support the httpapi working group spending time on the standardization effort.

Perhaps I am wrong to think that success of adoption should be a criterion for standardization.  Maybe if some segment of the community will benefit, then that meets the bar.  I'm fairly new to the process of WGs so I am open to guidance here.

Thanks,

Darrel

---

From: Mike Amundsen <[email-masked]>
Date: Sun, 21 Mar 2021 00:17:24 +0000 (UTC)

The ability to negotiate profiles has been an underlying assumption for the ALPS[1] media type -- now ten years on.
I think there are a number valuable use cases for this idea and I'd be happy to see it find a home in the HTTPAPI working group.
No matter where it ends up, I support it and would be happy to help it along.

[1] draft-amundsen-richardson-foster-alps-06 - Application-Level Profile Semantics (ALPS)

| 
| 
|  | 
draft-amundsen-richardson-foster-alps-06 - Application-Level Profile Sem...

Application-Level Profile Semantics (ALPS) (Internet-Draft, 2021)
 |

 |

 |

MCA
Mike Amundsen 
[email-masked] 

    On Saturday, March 20, 2021, 05:43:59 PM EDT, Darrel Miller <darrel.miller=[email-masked]> wrote:  
 
 #yiv0976507746 P {margin-top:0;margin-bottom:0;}First off, as a co-chair of the HTTPAPI working group, apologies for not being present in the dispatch meeting.
Speaking as an individual, my concern with this proposal is that while I do understand the value that this proposal brings, my experience is that the vast majority of API practitioners do not care.   Trying to sell the value of self-descriptive HTTP responses has mostly fallen on deaf ears for the last 15 years, and I don't see anything that is changing that sentiment.  
The notion of using profile to further qualify a media type is something that a number of people in the industry have tried to promote for years and it has gained very little traction.  I don't believe standardization of negotiation and discovery will change that.
Fundamentally, most API practitioners don't see the negative system impact of coupling a resource identifier with response semantics.  When they call GET /customer  and they get application/json back they don't see a problem with assuming the properties of that payload contain customer information.  Sure, it violates REST's self-descriptive constraint, but try convincing an API developer to care.  I spent many years trying unsuccessfully.  The popularity of API description formats is evidence that devs don't care about the coupling introduced by connecting response semantics with resource identifiers.
In the dispatch meeting, the assertion was made that profiles enable versioning.  But so does changing the resource identifier, which is the common practice today. I have zero technical objections to the principles presented in the RFC, in fact I support them.  But I strongly believe that history has demonstrated that they will not get mainstream adoption and hence I am reluctant to support the httpapi working group spending time on the standardization effort.  
Perhaps I am wrong to think that success of adoption should be a criterion for standardization.  Maybe if some segment of the community will benefit, then that meets the bar.  I'm fairly new to the process of WGs so I am open to guidance here.
Thanks,
Darrel

-- 
httpapi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/httpapi