77

私は一般的にRESTfulAPI設計のファンですが、検証APIにREST原則を適用する方法がわかりません。

ユーザーのプロファイル情報（名前、電子メール、ユーザー名、パスワード）を照会および更新するためのAPIがあるとします。公開する機能の有用な部分は検証であると考えています。たとえば、特定のユーザー名が有効で使用可能かどうかを照会します。

この場合のリソースは何ですか？どのHTTPステータスコードやヘッダーを使用する必要がありますか？

まず、GET /profile/validateクエリ文字列paramsを受け取り、有効か無効か204を返します。400しかしvalidate、明らかに動詞であり、名詞ではありません。

4

5 に答える 5

52

あなたが説明したタイプのことは、確かにそのセマンティクスにおいてよりRPCスタイルですが、それはあなたがRESTfulな方法であなたの目標を達成できないことを意味しません。

HTTP動詞はないVALIDATEので、その周りにAPI全体を構築することでどのくらいの価値を得ることができますか？あなたのストーリーは、特定のユーザー名が使用可能かどうかをユーザーが判断できるようにすることを中心にしています。これは、単純なリソース取得チェックのように聞こえ GET: /profile/username/...ます。結果が404の場合、その名前は使用可能です。

これが強調しているのは、そのクライアント側の検証がまさにそれであるということです-クライアント側。サーバーに送信する前にデータがクライアントで検証されていることを確認することは、UIの問題です。RESTfulサービスは、クライアントが検証を実行したかどうかにかかわらず、聖霊降臨祭を提供しません。独自の検証ロジックに基づいて、要求を受け入れるか拒否するだけです。

RESTは包括的なパラダイムではなく、クライアント/サーバー通信を構造化する方法を説明するだけです。

于 2012-07-26T19:41:44.953 に答える
21

同じ問題が発生しました。検証のためにクライアントをサーバーに延期させる理由は、ルールの不一致を防ぐためです。サーバーは、リソースを操作する前にすべてを検証する必要があります。これらのルールを2回コーディングして、同期が外れる可能性があることは意味がありませんでした。したがって、RESTの考え方に沿っているように見えると同時に、サーバーに検証を実行するように依頼できる戦略を考え出しました。

最初のステップは、メタデータサービスから要求できるメタデータオブジェクトを実装することでした（GET /metadata/user）。次に、このメタデータオブジェクトを使用して、基本的なクライアント側の検証（要件、タイプ、長さなど）を実行する方法をクライアントに指示します。これらのほとんどはデータベースから生成されます。

2番目の部分は、分析と呼ばれる新しいリソースを追加することで構成されます。たとえば、サービスがある場合：

GET /users/100

次のような新しいリソースを作成します。

POST /users/100/analysis

分析リソースには、発生した検証エラーだけでなく、必要に応じて関連する可能性のある統計情報も含まれています。私たちが議論した問題の1つは、分析リソースにどの動詞を使用するかということでした。リクエスト時に分析が作成されているため、POSTである必要があると結論付けました。ただし、GETについても強い議論がありました。

これが同じ問題を解決しようとしている他の人に役立つことを願っています。この設計に関するフィードバックをいただければ幸いです。

于 2016-02-19T14:30:55.873 に答える
11

あなたはRESTをリソース指向と混同しています。RESTにはURLで動詞を使用できないと言っているものは何もありません。URLデザインに関しては、私は通常、最も自己記述的なものを選択します。それは名詞または動詞です。

あなたのサービスについて、私がすることは、更新に使用するのと同じリソースを使用しますが、testクエリ文字列パラメーターを使用するためtest=1、操作が完了していない場合でも、検証エラーを返すために使用できます。

PATCH /profile?test=1
Content-Type: application/x-www-form-urlencoded

dob=foo

...そして応答：

HTTP/1.1 400 Bad Request
Content-Type: text/html

<ul class="errors">
  <li data-name="dob">foo is not a valid date.</li>
</ul>
于 2012-07-26T21:58:36.497 に答える
0

非常に一般的なシナリオは、一意である必要があるユーザー名と電子メールを含むユーザーまたはプロファイルのサインアップフォームを用意することです。通常、テキストボックスのぼかし時にエラーメッセージが表示され、ユーザー名がすでに存在するか、入力した電子メールがすでに別のアカウントに関連付けられていることをユーザーに知らせます。他の回答で言及されているオプションはたくさんありますが、ユーザー名が存在しないことを意味する404を探す必要があるという考えは好きではありません。したがって、有効であり、送信を待ってオブジェクト全体を検証し、検証のためにメタデータを返します一意性のチェックには役立ちません。

Imo、検証が必要なフィールドごとにtrueまたはfalseを返すGETルートが必要です。

/users/validation/username/{username}

と

/users/validation/email/{email}

サーバー側の検証が必要な他のフィールドには、このパターンで他のルートを追加できます。もちろん、POSTでオブジェクト全体を検証することもできます。

このパターンでは、ユーザーを更新するときに検証することもできます。ユーザーがメールのテキストボックスに注目し、クリックしてぼかしの検証を実行した場合、現在のユーザーに関連付けられている限りメールが既に存在する場合は問題ないため、わずかに異なる検証が必要になります。trueまたはfalseを返すこれらのGETルートを利用できます。

/users/{userId:guid}/validation/username/{username}

と

/users/{userId:guid}/validation/email/{email}

この場合も、オブジェクト全体をPUTで検証する必要があります。

于 2021-05-18T12:45:41.693 に答える
-2

RESTAPIで検証できるのは素晴らしいことです。とにかく検証が必要であり、クライアント側では使用しないでください。私の場合、APIには、特別なerror_idが検証エラーを表すという規則があり、error_detailsには、このPUTまたはPOST呼び出しでエラーが発生した各フィールドのエラーメッセージの配列があります。例えば：

{
  "error": true,
  "error_id": 20301,
  "error_message": "Validation failed!",
  "error_details": {
    "number": [
      "Number must not be empty"
    ],
    "ean": [
      "Ean must not be empty",
      "Ean is not a valid EAN"
    ]
  }
}

Webアプリケーションとモバイルアプリケーションに同じRESTAPIを使用する場合は、APIを更新するだけで両方の検証を変更できるようになります。特にモバイルアップデートは、ストアに公開されるまでに24時間以上かかります。

そして、これはモバイルアプリケーションでどのように見えるかです： ここに画像の説明を入力してください

PUTまたはPOSTの応答は、各フィールドのエラーメッセージを表示するために使用されます。これは、Reactを使用したWebアプリケーションからの同じ呼び出しです。 ここに画像の説明を入力してください

このように、200、404などのすべてのREST API応答コードは、本来あるべき意味を持っています。検証が失敗した場合でも、PUT呼び出しは200で応答します。呼び出しが検証に合格した場合、応答は次のようになります。

{
  "error": false,
  "item": {
"id": 1,
"created_at": "2016-08-03 13:58:11",
"updated_at": "2016-11-30 08:55:58",
"deleted_at": null,
"name": "Artikel 1",
"number": "1273673813",
"ean": "12345678912222"
  }
}

あなたが行うことができる可能な変更があります。Mabyはerror_idなしでそれを使用します。error_detailsがある場合は、それらをループし、フィールドと同じ名前のキーを見つけた場合は、エラーテキストとしての値を同じフィールドに配置します。

于 2016-11-30T08:08:32.263 に答える