我正在定义一个API，并且遇到了一个我以前无需处理的问题。我想知道这里的共识是什么样的最佳状态代码可用于尚未知道结果的响应。
为了解释，有问题的GET端点不返回资源，它只是返回有关已知日期的特定信息的工具。
它用于执行此操作的后端日历数据会定期手动加载到块中。因此，如果用户查询已加载日期范围之外（或之前）的日期，API应如何响应？
最初我在考虑4xx错误，但语法和查询在技术上是有效的。在另一个时间尝试完全相同的查询（当加载该日期的数据时）将导致成功的响应。
看看5xx错误，非似乎是一个理想的匹配。 503服务不可用看起来最接近我，但似乎专注于临时错误。这种情况可能持续数月。复合问题是API本身不知道何时将加载更多数据，因此我们也不能轻易使用Retry-After标头。
你会怎么做？谢谢！
202 Accepted意味着服务成功接受了请求，并且到目前为止没有任何问题（即没有立即的数据验证问题），但它在进行进一步处理之前无法创建资源。但是，此响应不保证将创建资源。因此，它非常适合待处理的请求，因为待处理的请求可能会在处理时被拒绝。
附加qazxsw poi header以及endpoit服务异步操作的实际状态也是导入的，这样客户端就能定期监视它。
请勿使用4xx或5xx HTTP状态代码。
只有在请求或响应中出现错误时才应使用它们，而不是。
4xx错误意味着请求失败（它没有），5xx意味着服务器错误。
绝对使用2xx回复，200 OK或202 Accepted
为了解释，有问题的GET端点不返回资源，它只是返回有关已知日期的特定信息的工具。
这是Location意义上的资源。
REST中信息的关键抽象是一种资源。可以命名的任何信息都可以是资源：文档或图像，临时服务（例如“洛杉矶的今天天气”），其他资源的集合，非虚拟对象（例如人）等等。换句话说，任何可能是作者超文本引用目标的概念都必须符合资源的定义。资源是到一组实体的概念映射，而不是与任何特定时间点的映射相对应的实体。
特别是，某些东西是资源这一事实并不以任何方式取决于用于提供资源表示的实现。
如果用户查询的日期超出（或之前）已加载的日期范围，API应如何响应？
通常通过返回一个消息体来向客户端解释问题所在，并在元数据中包含一个响应代码，用于指示对通用组件的响应的性质。
特别是，您希望关注缓存如何与您的响应进行交互，因为它们只会查看元数据，而不是有效负载。
在大多数情况下，您需要报告错误并指示缓存存储响应以供以后使用。
因此，您需要使用状态代码REST。
404（未找到）状态代码表示源服务器没有找到目标资源的当前表示，或者不愿意透露存在该目标资源。
实际上，404 Not Found暗示目标-ur的拼写是错误的，或者客户不应该要求这个特定的资源。在任何一种情况下，它都是请求的问题，应该以这种方式处理。
在另一个时间尝试完全相同的查询（当加载该日期的数据时）将导致成功的响应。
请注意，HTTP标准明确指出404可能在临时条件下使用的事实：
404状态代码不表示缺少表示是暂时的还是永久的