そこで、REST API インターフェイスに関して最近行った多くの調査に基づいて、理論的な質問があります。
まず、REST では、リソースは動詞ではなく名詞である必要があり、各リソースは次のリソースから分離する必要がありますが、リソースの目的に応じて、リソースは同じエンティティまたはエンティティのコレクションを返すことができることを理解しています。
ただし、私の焦点は、安らかな検索を実行することです。
私が行ったすべての調査で、私が見つけた最も一般的な解決策は、URL でパラメーターを使用することです。
api.test.com/search-cars?param1=val1¶m2=val2
これは標準的な慣行であり、REST のルールを実際に破っているわけではありませんが、検索パラメーターを ID (おそらく JSON の形式) として表す人がいないのはなぜですか?
api.test.com/cars/{"color":"blue","year":"2013","make":"toyota"}
車をリソースとして見て、ID を JSON として表すと、私は本当に有限の数の車を持っているため、ID の有限かつ一意の数を持っていると簡単に言えます。
さらに、これは「resource/id」に準拠することで純粋な休息を促進します
最初の例のようにパラメーターを使用する利点と欠点は何ですか?
2 番目の例のように、JSON を「フィルター」で ID として使用する利点と欠点は何ですか?
API の最初のリソースをどのように進めていくかについて最終決定を下す必要があるため、すべてのコメントは本当に役に立ちます。また、なぜ私がどちらの方法を選択したのかを上司に説明するための強力な議論が必要です。