Re: Communicating Warning Information in HTTP APIs

André Cedik <andre.cedik@googlemail.com> Tue, 19 November 2019 05:13 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0327A1207FB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 18 Nov 2019 21:13:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNKwyQikcwyI for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 18 Nov 2019 21:13:10 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3985712001E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 18 Nov 2019 21:13:10 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iWvmc-0008DQ-Tr for ietf-http-wg-dist@listhub.w3.org; Tue, 19 Nov 2019 05:10:34 +0000
Resent-Date: Tue, 19 Nov 2019 05:10:34 +0000
Resent-Message-Id: <E1iWvmc-0008DQ-Tr@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <andre.cedik@googlemail.com>) id 1iWvma-0008Cb-Nr for ietf-http-wg@listhub.w3.org; Tue, 19 Nov 2019 05:10:32 +0000
Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <andre.cedik@googlemail.com>) id 1iWvmW-0003WQ-ML for ietf-http-wg@w3.org; Tue, 19 Nov 2019 05:10:32 +0000
Received: by mail-wm1-x32f.google.com with SMTP id z26so1669176wmi.4 for <ietf-http-wg@w3.org>; Mon, 18 Nov 2019 21:10:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RYNMAjuNEiOXmvoq3c1N3qf79K5YqtAqnc8Jz2iHDME=; b=FBfS4/fsdxBeOlfVqrddqyKMk80Efh0kfAfOLE03Z4iQvNx33WnSeCRoVbOsDk2YIn S6hVtHo33KsSQSWRXjCiLwvor7sZ6gnYgGlk27624M3O4+SgpsVMiW3aFk5ew2jW3T6h 5LIvJTCpJx57jgK8zBWdowSSlxkpxQ4KuB3pyHP6Xo71fMUIlzOKdH6wEugLORD0AHPL YH8gVZJ2HEiRpQJK/RPrMwse3o22GjeDPMsIX26l48qUGu7GDm7lKFhKCplvVUxCcN9F Y++g+6rZytexHv7QJlzQy8Bfzgw1c7OABZV3mvJZpUs2MHe6Il2p+BbLRCCVRDk2JeCK B4hQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RYNMAjuNEiOXmvoq3c1N3qf79K5YqtAqnc8Jz2iHDME=; b=HUglnbywOEhX8BJHMqKHqMHPEsMrj81Ln5kjFM+nNJWbrO1MrEj0Eq807bkYxUUSnM /9vwvDpCZY3LJjl1dQEUlnXiQdm6fFELgQNOboFwDttJlixnGlc+DFNdd6pz1n/5NQty XJoc2ec++ckDP7JN8sadojZfrQmnoI6SiWjVcQQCbdhD6qeuvoEheGx3yOwnpmzh/a95 07cZIYwg8R78EXottBLaSdRS2sVHoTsuXdmNU8UJMgkl/FqNJlH8CWquj8DI7G/8e81z O1L08gq4nxTFPCtwCO7tjpb08prvlq/YCAyLyhfhLcbUNjTQNVRnUgXP02P1CMREsDob dX3g==
X-Gm-Message-State: APjAAAUZonHtgDova+pIvpmUUN0dg+6FAP5M50lsiMB17R0GloMPA6NH lxDkml4FfqtYqpyRvAe7kfKbo83UGSgAgsb8csSMfwYMPsw=
X-Google-Smtp-Source: APXvYqxmcm5Nu/gN6dRAG486VjqTv20ymo6Mms0f1+z7T44eaYN6lqMrq1Ew8WebruiJPWiCnTzaosfX6Dr/PoTAaIc=
X-Received: by 2002:a1c:40c1:: with SMTP id n184mr3446006wma.116.1574140226282; Mon, 18 Nov 2019 21:10:26 -0800 (PST)
MIME-Version: 1.0
From: André Cedik <andre.cedik@googlemail.com>
Date: Tue, 19 Nov 2019 06:10:15 +0100
Message-ID: <CAEQcYZhSM+bHH=Mpz1wjD=e6q=Rws+C4Lh_2_6bvhOAqgBHmmQ@mail.gmail.com>
To: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="00000000000003ab4a0597ac15b9"
Received-SPF: pass client-ip=2a00:1450:4864:20::32f; envelope-from=andre.cedik@googlemail.com; helo=mail-wm1-x32f.google.com
X-W3C-Hub-Spam-Status: No, score=-2.2
X-W3C-Hub-Spam-Report: BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1iWvmW-0003WQ-ML d70111649c86d27ef5d49ad658e8646d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Communicating Warning Information in HTTP APIs
Archived-At: <https://www.w3.org/mid/CAEQcYZhSM+bHH=Mpz1wjD=e6q=Rws+C4Lh_2_6bvhOAqgBHmmQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37146
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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é