これは本当に機能以上に名前を付けることについての議論です。 APIで処理されたロジックを持つことは非常に可能です。名前をつけるだけで十分です。
想像上のAPI時間。そのリソースには/v1/probe/{ID}
があり、GET、POST、DELETEに応答します。
私たちはプローブを起動し、プローブが観測したものの計算された磁束変化(完全に構成されたもの)を返すようにしたいとしましょう。本当のことではありませんが、これをオンザフライで計算する必要があるとしましょう。私の勇敢なチームメイトの1人が、計算をGET /v1/1324/calculateflux
にすることに決めました。
私たちが本当のREST-fulの慣行に従っているなら...おっと。突然私たちは名詞を扱っていないのですか? GET /v1/probe/1324/calculateflux
がある場合は、動詞 - calculateflux
を求めているので、RESTfulな方法が壊れています。
私たちはこれにどのように対処しますか?
名前はcalculateflux
です。それは良いことではありません - それはプローブ上のリソースを指定しません。 **この場合、/v1/probe/1324/fluxvalue
はより良い名前で、/v1/probe/1324/flux
も有効です。
なぜですか?
RESTFUL APIは、ほぼ例外的にURIに名詞を使用します。各URIはPOST PUTまたはDELETEなど何かを得ることができる特定のものを記述する必要があります。 つまり、処理された値があるときはいつでも、リソースに処理済み(または計算済み)の値を渡す必要があります。この方法では、常に最新のデータ(Fluxの値をいつでも再計算できます)とプローブの状態を変更していない(GETを使用して値を保存していない)ことによってRESTfulのままです。
翻訳は動詞です(翻訳を使用できます).GETで送信されるテキストの長さは制限されます。長時間実行されるプロセスは問題ではありませんが、APIの正確さ(+要求を格納するすべてのロジック)のためにPOST/PUTとGETを実行することは、過度の使用であり、ユーザーフレンドリーではありません。 – Alfons
@ Alfons:この架空の翻訳サービスが基本的に辞書の場合は、リクエストを保存する必要はありません。約4096文字(IE6)のGET要求の制限はそれ以上で十分です。それが長いテキストの翻訳が人が提供するサービスであるGengoのようなものだったら、長期的なプロセスリソースが必要です。実際のケースについて詳しく説明して、より詳細な提案をすることができますか?また、APIの正確さはユーザーフレンドリーではないというご意見に同意します。 WebはAPIの正確さ(RESTfulness)のために非常に正確に機能します。 –