Javascript Fetch API 太快；在第二个 HTTP(获取 api)请求之前完成

Question

我有 2 个使用 Javascript 中的 Fetch API 的 HTTP 请求。我的主要语言是 Java，但我的任务是负责一个前端项目，所以我不确定是否有一个简单的解决方案。我的问题是，第一个调用(命中随机服务器)命中的外部终结点与第二个外部终结点(该终结点位于 Azure 上)不同，但第二个终结点依赖于第一个终结点。基本上，第一个端点是一个 POST 请求，用于在 Azure 网站(IoT 中心)上创建/填充对象/IoT 设备。因此，第二个请求实际上无法执行任何操作(在本例中为 PATCH)，直到设备显示在网站上。我注意到它通常需要几秒钟，比如 1-5 秒才会出现。

我的 Fetch API 看起来像这样:

fetch('https://first-API-endpoint-on-random-server.com/creates-thing-on-Azure', {
  method: 'POST',
  headers: myHeaders,
  body: JSON.stringify(data),
})
.then(response => response.json())
.then(data => {
  console.log('Success:', data);

  // Beginning of nested Fetch
  return fetch('https://second-DIFFERENT-API-endpoint-on-azure.com/tries-to-edit-thing-on-Azure', {
      method: 'PATCH',
      headers: myHeaders,
      body: JSON.stringify(data),
    })
    .then(response => response.json())
    .then(data => {
      console.log('Success:', data);
    })
    .catch((error) => {
      console.error('Error:', error);
    });
})

所以基本上，您单击我的网站 UI 上的按钮，它应该运行此 onClick 函数，并通过第一个 Fetch API 调用在 Azure 上创建/填充对象/IoT 设备，然后第二个 Fetch API 调用应该“修补” "或编辑 JSON。

第一个 API 调用总是有效但问题是第二个 API 调用似乎总是因 404“设备未找到”错误而失败，因为我认为第一个调用也已完成很快，然后第二个调用尝试修补网站上尚不存在的内容。我的解决方案是将 API 调用划分/拆分到两个不同的点击事件，这解决了问题，因为当用户单击第二个按钮时，第二个 Fetch API 调用/PATCH 通常总是成功.

我真的很想将它们组合成一个函数，这样用户就永远不会知道 PATCH 事件/http 调用。我怎样才能让第二次 Fetch 真正起作用？

我可以提供您想要的任何详细信息，谢谢

Answer 1

服务器对初始请求的 200 响应似乎表明该请求已正确处理，但并不表明该资源已在 Azure 上创建。资源是在服务器响应后一段时间在 Azure 上创建的，但客户端的第二个请求是在创建资源之前的一段时间发出的。以下是可能的请求和响应序列的时间表:

1. 客户端(网络浏览器)向服务器发出第一个 (POST) 请求。
2. 服务器接收请求，向 Azure 发出创建资源的请求，并返回 200 指示请求已被处理。此时，Azure 已收到请求并可能开始创建资源。
3. 客户端(网络浏览器)接收来自服务器的 200 响应，并继续发出第二个 (PATCH) 请求。此时，Azure 可能正在创建资源，但尚未完成创建，因此它返回 404。

此问题可以在后端解决，例如让服务器等待在 Azure 上创建资源，然后再向客户端响应 200。如果这是不可能的，则可以在客户端单独或组合采取两行操作:

• 在收到第一个请求的 200 后，等待一段固定的时间，然后再发出第二个请求。由于我们没有来自后端的有关资源创建时间的指示，因此我们可以选择任意时间量。下面是我们等待 1 秒的示例:

function createResource(data) {
  return fetch('https://first-API-endpoint-on-random-server.com/creates-thing-on-Azure', {
    method: 'POST',
    headers: myHeaders,
    body: JSON.stringify(data),
  })
}

function updateResource(data) {
  return fetch('https://second-DIFFERENT-API-endpoint-on-azure.com/tries-to-edit-thing-on-Azure', {
     method: 'PATCH',
     headers: myHeaders,
     body: JSON.stringify(data),
  })
}

function createAndUpdateResource(data) {
  return new Promise((resolve, reject) => {
    return createResource(data)
      .then(res => res.json())
      .catch(reject)
      .then(resourceData => {
        setTimeout(() => {
          // do we pass data or resourceData data to the PATCH request?
          updateResource(resourceData)
            .then(res => res.json())
            .then(resolve)
            .catch(reject)
          });
        }, 1000);
      });
  });
}

createAndUpdateResource({ name: "abc" })
  .then(res => {
    console.log("success:", res);
  })
  .catch(err => {
    console.log("error: ", err.message);
  });

• 对第二个请求使用重试机制。收到 404 错误后，我们可以对同一请求进行有限次数的重试。这可以与上述超时方法结合使用。下面是一个带有重试的示例实现:

function withRetry(apiCall, retryCount, timeoutMS, statusForRetry) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      apiCall()
        .then(res => {
          if (!res.ok) {
            if (res.status === statusForRetry && retryCount > 0) {
              return withRetry(
                apiCall,
                retryCount - 1,
                timeoutMS,
                statusForRetry
              );
            }
            reject(new Error("couldn't update"));
          }
          return res.json();
        })
        .then(resolve)
        .catch(reject);
    }, timeoutMS);
  });
}

function createAndUpdateResource2(data) {
  return new Promise((resolve, reject) => {
    return createResource(data)
      .then(res => res.json())
      .then(resourceData =>
        withRetry(
          () => updateResource(resourceData),
          3, // 3 retries
          1000, // wait 1 second
          404 // retry on 404
        )
      )
      .then(resolve)
      .catch(reject);
  });
}