1

ユーザー入力を検証するためのAPIを（Webサービスとして）作成することを計画しています。

APIは、入力としてユーザーから3つのパラメーターを取得し、すべてのパラメーターが有効であることを確認してから、結果（例：trueまたはfalse）をユーザーに返します。

そして、これがAPIの大まかなスケッチです（これがRESTfulだとは思えません）：

URL: http://my.domain.com/validate/v1 (POST)
Required parameter: param1, param2, param3
Result: To response body (XML/JSON) or response header (HTTP status)

しかし、APIデザインとRESTをグーグルで調べたところ、このAPIデザインに問題があることがわかりました。

ウィキペディアによると、リクエストとレスポンスは、リソースの表現の転送を中心に構築されています。しかし、私が作成しているAPIはリソースとは何の関係もありません。リソースをCRUDしません。APIが行うのは、入力を取得して検証し、結果を返すことだけです。そして、私はこの要件でAPIを設計することに固執しています。

この質問に対するアドバイス/訂正は大歓迎です。

4

1 に答える 1

2

問題がRPCスタイルによりよく適合することは正しいですが、それでもRESTに簡単にマッピングできます。これが私がそれをする方法です：

POSTメソッドは、新しいリソースを作成するためにRESTで頻繁に使用されます。この新しいリソースの表現は、同じタイプのリソースのコレクションを表すURLに投稿されます。操作が成功すると、HTTPステータスコード「201Created」が、repose本文（基本的には投稿で送信されたものと同じメッセージ本文）に表示されて返されます。返されるContent-Locationヘッダーには、新しいリソースに割り当てられたURLが表示されます。操作が失敗した場合は、「400 Bad Request」ステータスコードと、メッセージ本文に人間が読める形式のより詳細なエラーの説明が表示されます。

ご覧のとおり、検証はすでにこの一般的なRESTパターンの一部です。私が理解していることによると、あなたの場合の唯一の違いは、サーバー上にこのリソースを作成（記憶）したくないということです。だからしないでください。RESTはあなたがしなければならないと言っていません。簡単な場合は、リソースが実際に一時的に作成されたが、その後すぐに削除されたと想像してください。パラメータが検証に合格した場合はステータスコード「200OK」を返し、メッセージ本文のパラメータも返します。それ以外の場合は「400BadRequest」を返します。

動詞「validate」がURLで気になる場合は（そうすべきではありません）、URLに別の名前を付けます。おそらく、3つのパラメーターで構成されるオブジェクトの適切な名前になります。

お役に立てれば

Ferenc Mihaly http://theamiableapi.com

于 2012-04-25T13:52:56.247 に答える