web-dev-qa-db-ja.com

検証APIをRESTfulな方法で公開する方法は？

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

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

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

はじめに、GET /profile/validateクエリ文字列パラメーターを受け取り、204または400有効または無効の場合。しかし、validateは明らかに動詞であり、名詞ではありません。

apihttprest
63
Aseem Kishore

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

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

これが強調するのは、そのクライアント側の検証がまさにそれであるということです-クライアント側。データがサーバーに送信される前にクライアントで検証されることを確認することはUIの懸念事項です。 RESTfulサービスは、クライアントが検証を実行したかどうかに関係なく、何もしません。独自の検証ロジックに基づいて、リクエストを単に受け入れるか拒否します。

RESTはすべてを網羅するパラダイムではなく、クライアントとサーバー間の通信を構築する方法を説明するだけです。

43
Josh E

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

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

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

GET /users/100

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

POST /users/100/analysis

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

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

13
Leslie Hanks

あなたは混乱しているREST=リソース指向、RESTには何もありません。最も自己記述的な、ウィザーは名詞または動詞です。

あなたのサービスについて、私がやることは、更新に使用するのと同じリソースを使用しますが、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>
10
Max Toro

REST 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"
    ]
  }
}

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

そして、これがモバイルアプリケーションでの表示方法です。 enter image description here

PUTの応答またはPOSTは、各フィールドのエラーメッセージを表示するために使用されます。これは、Reactを使用するWebアプリケーションからの同じ呼び出しです。 enter image description here

このように、すべてのREST 200、404のような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である場合、それらをループし、フィールドと同じ名前のキーを見つけた場合、そのフィールドの値をエラーテキストとして入力します。

0
Tarik Huber