W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

Re: Communicating Warning Information in HTTP APIs

From: Asanka Herath <asanka@chromium.org>
Date: Tue, 19 Nov 2019 12:07:13 -0500
Message-ID: <CAM=uaOEhWDBgdCoPrKLy5NktMxs=v22uNck0DjLS4dcwWRqtUA@mail.gmail.com>
To: André Cedik <andre.cedik@googlemail.com>
Cc: ietf-http-wg@w3.org
Is there a use case where the Warning header is required to be a HTTP
header instead of being encoded into the body?

As proposed it seems the Warning header could ossify into a generic
metadata channel that is of no utility to a generic UA.

On Tue, Nov 19, 2019 at 12:13 AM André Cedik <andre.cedik@googlemail.com>

> Sorry for getting back to you so late. I was sick for more than a week and
> had no chance to answer at all.
> First of all thank you for the Feedback Mark.
> I'm a little conflicted as to where we should discuss this further. Since
> Roy recently answered to this issue (
> https://github.com/dret/I-D/issues/125), the discussion over there is
> moving a little faster.
> Nonetheless, I would love to tell you the use case(es) from which the
> original idea for the I-D was born. The company I'm working for is a
> shipping service provider. This means that we've integrated shipping
> carriers like UPS, DHL, TNT, etc. into a single platform and are providing
> them via our own api to our customers.
> One of the most basic things you can do with the api is creating a
> shipping label for sending a parcel from point a to point b. You can either
> use one of the carrier contracts we provide to buy the shipping label or
> you can use your own account with a carrier. This means that either we
> charge our customer for the label or the carrier does this directly.
> Unfortunately there are cases, where the service of a shipping carrier
> creates a shipping label and therefore charges (either us or the customer)
> for their service, but in the backend not everything went perfect. Let me
> clarify this:
>    - we send the data to the web service of the carrier
>    - the carrier creates the shipping label and returns it to us
>    - since not all data was 100% correct, the carrier also returns
>    annotations, that they've done something (to the request) to "make it work"
> The thing is we need to inform the customer of this automatic behaviour
> that is out of our hand, since they can get charged extra for what the
> carrier has done in the background.
> I'm hoping that I was able to shed a bit of light into what at least our
> use case is. We're currently on the lookout for more use cases which I'm
> sure are out there, to get a better understanding about we can create a
> generalized approach to communicating errors in http apis.
> All the best
> André
Received on Tuesday, 19 November 2019 17:20:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC