Re: [dispatch] [httpapi] HTTP profile negotiation -- implementation evidence (was: HTTP profile negotiation - httpapi?)

[Mike Amundsen <[e-mail]>]

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 
[e-mail] 

    On Saturday, March 20, 2021, 05:43:59 PM EDT, Darrel Miller <darrel.miller=[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/httpapi