Api 如何在各个领域使用搜索方法设计资源？

我正在为类似字典的服务设计RESTAPI。我们的目标是支持多种语言，但我将以中文为例（iso代码：

cmn

）

我认为我的字典是资源，例如我得到：

• ← 中国人
• ← 日文

对于每种语言，我希望在以下字段中允许模糊搜索：

• ort

  ：主要正字法（如简体中文）

• ortx1

  ：第一个额外的正字法（如繁体中文）

• pho

  ：拼音（如汉语拼音）

• def

  ：法语翻译

现状 目前我的API是这样的：

/api/
    ├── dicts/
    │   ├── cmn/
    │   │   ├── any/{text}
    │   │   ├── ort/{text}   # Simplified
    │   │   ├── ortx1/{text} # Traditional
    │   │   ├── pho/{text}   # Pinyin
    │   │   ├── def/{text}
    │   ├── jpn/
    │   │   ├── any/{text}
    │   │   ├── ort/{text}   # Kanji
    │   │   ├── ortx1/{text} # Hirgana/Katakana
    │   │   ├── pho/{text}   # romaji
    └───└───└── def/{text}   

我应该保留当前的api布局还是切换到另一个

../cmn/{field}/{text}

当前

../cmn/{text}/{field}

../cmn/{text}？{field}

使用查询字符串参数调整我的搜索

代码>…/搜索/ {Lang}/{Field}/{Te}} /代码>将搜索视为资源；<李>

---

在我看来，字段参数（ort、ortx1等）实际上不符合独立资源的条件。此外，如果您看到，这些字段是公共的，并且在每个cmn子树下重复

更直观的方法似乎是第三种方法，因为字段只是搜索中的一个限制。这还提供了一种更简单的方法来允许默认搜索模式，如果您将字段用作资源，则默认搜索模式将违反直觉且不明确

第二种方法还面临允许默认搜索模式的问题，字段显然不是文本的子资源

---

如果您将

{field}

作为资源删除，并将其作为查询参数添加，那么您提到的第四种方法看起来是合理的。

是否有不使用查询参数的充分理由？GET/API/DISTS/CMN？ORT= {文本}和PHO= {Te}}，我也会考虑一个没有把你和法语翻译联系起来的设计，以免你成为自己成功的牺牲品。