【问题标题】:Parameter not supported by web serviceWeb 服务不支持的参数
【发布时间】:2012-12-17 14:03:04
【问题描述】:

我想和你一起验证一个意见。

我必须设计一个 Web 服务,该服务可以搜索与给定地址周围的特定国家/地区的折扣计划相关的餐厅数据库。 对此类 Web 服务的 REST 调用将类似于 http://server/search?country=<countryCode>&language=<languageCode>&address=<address>&zipcode=<zipcode>

问题是有些国家没有邮政编码,或者整个国家都没有。

现在,如果用户为一个没有邮政编码的国家/地区传递了这样一个参数,但他/她传递了一个有效的地址,你会怎么做?

  1. 返回 400 错误请求。
  2. 只需输入 zipcode 参数,根据有效地址返回结果
  3. 以特定格式(例如 JSON)返回错误消息,说明该国家/地区不支持邮政编码

一些同事也赞成以下选项 4. 简单地不返回任何结果。并在文档中声明不支持 zipcode 参数。我们还必须创建一个 webservice 方法,它返回应该在用户界面中显示的字段。

你认为哪个选项最好,为什么?

谢谢!

【问题讨论】:

    标签: web-services rest language-agnostic


    【解决方案1】:

    即使您不知道邮政编码,OpenStreetMap 提名服务器也会返回结果,并且无论如何您都可以查看结果。如果用户不知道邮政编码但想查找历史对象怎么办? 无论如何,我都会尝试搜索该特定对象,尤其是因为您说某些国家/地区有部分邮政编码。

    如果你什么都不返回,用户不知道出了什么问题,他也不知道该怎么办。

    【讨论】:

      【解决方案2】:

      这将取决于用例。 API 的用户触发这种情况有多容易?这是一个用户真的应该知道如何避免的严重错误吗?还是不是完全清楚,用户可能知道(或认为他知道)一个官方不应该有的邮政编码?用户如何从您的 API 中检索正确的结果是否归结为反复试验?用户需要被告知并需要他自己处理这个错误是否已经够糟糕了?

      如果您在 API 中设置此限制,请考虑在触发此案例时必须清楚地记录它,API 的每个用户都必须阅读并理解该文档,需要明确如何避免问题,用户需要有可能避免该问题,并且每个用户都必须在他的身边正确地实现额外的代码来避免这个问题。用户是否可以轻松知道哪些区域有邮政编码,哪些没有?

      我认为“接受的要灵活,输出要严格”的口号适用......

      【讨论】:

        猜你喜欢
        • 2018-11-04
        • 2013-05-25
        • 1970-01-01
        • 2016-08-12
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-10-16
        • 1970-01-01
        相关资源
        最近更新 更多