配置

通常，EVE構成はプロファイルを用いて行うことが望ましい.プロファイル自体が実際のPythonファイルです。しかし，EVEはまず辞書ベースの設定を優先し，入力された文書の検索を試みる EVE_SETTINGS 環境変数(設定すれば)は、最後に位置を特定しようとします settings.py ファイル名が渡されたファイル settings 構造関数中のフラグ.

ファイルを用いて構成する

起動時に settings 構造関数ではフラグが省略されており，イヴは名前を位置づけることを試みる settings.py まず、アプリケーションフォルダに格納され、その後、アプリケーションの1つのサブフォルダに格納される。アプリケーションをインスタンス化する際にパラメータとして渡すだけで、別のファイル名/パスを選択することができます。ファイルパスが相対パスである場合、イヴは再帰的にあなたの sys.path したがって、あなたはアプリケーションルートをそれの後に追加することを確実にしなければならない。たとえば，設定ファイルが必ずしもアプリケーションのルートディレクトリにあるとは限らない場合，これはテスト環境において有用である.

from eve import Eve

app = Eve(settings='my_settings.py')
app.run()

辞書を用いて配置する

あるいは、設定辞書を提供することも選択できます。設定ファイル構成Eveを使用するのとは異なり、辞書ベースの方法は、すべての設定をカバーすることなく、ご自身の値を使用してイヴのデフォルト設定を更新するだけです。

from eve import Eve

my_settings = {
    'MONGO_HOST': 'localhost',
    'MONGO_PORT': 27017,
    'MONGO_DBNAME': 'the_db_name',
    'DOMAIN': {'contacts': {}}
}

app = Eve(settings=my_settings)
app.run()

開発·生産

ほとんどのアプリケーションは複数の構成を必要とする.生産サーバと開発期間中に使用するサーバは少なくとも異なる構成であるべきである.この問題に対処する最も簡単な方法は，つねにロードされているデフォルト構成およびバージョン制御の一部を使用することと，必要に応じてこれらの値をカバーする個別構成を用いることである.

これがファイルコンテンツを使用して設定を上書きまたは拡張することができる主な理由です。 EVE_SETTINGS 環境変数指向.開発/ローカル設定は、ストレージに格納することができます settings.py そして、生産では、EVE_SETTINGS=/PATH/を/Production_setting.pyに導出することができます。

しかし、開発/生産を処理する多くの代替方法がある。Pythonモジュールを使用して構成することは非常に便利です。ローカルおよび生産システム上で同じAPIをシームレスに起動し、必要に応じて適切なデータベースインスタンスに接続することができるなど、様々なテクニックを使用することができます。以下の例を考える.

# We want to run seamlessly our API both locally and on Heroku, so:
if os.environ.get('PORT'):
    # We're hosted on Heroku! Use the MongoHQ sandbox as our backend.
    MONGO_HOST = 'alex.mongohq.com'
    MONGO_PORT = 10047
    MONGO_USERNAME = '<user>'
    MONGO_PASSWORD = '<pw>'
    MONGO_DBNAME = '<dbname>'
else:
    # Running on local machine. Let's just use the local mongod instance.

    # Please note that MONGO_HOST and MONGO_PORT could very well be left
    # out as they already default to a bare bones local 'mongod' instance.
    MONGO_HOST = 'localhost'
    MONGO_PORT = 27017
    MONGO_USERNAME = 'user'
    MONGO_PASSWORD = 'user'
    MONGO_DBNAME = 'apitest'

全体構成.

従来のAPIアクションを定義することに加えて、多くのグローバル構成設定は、標準エンドポイントルールセットを定義するために使用され、単一のエンドポイントを後で構成する際に微調整することができる。グローバル配置はつねに大文字に設定されている.

URL_PREFIX	すべてのAPIサイトのURLプレフィックス.将と API_VERSION APIエンドポイントを構築するために(例えば、 api 私たちの目の前にある /api/<endpoint> ）。黙認する. '' それがそうです。
API_VERSION	APIバージョン。将と URL_PREFIX APIエンドポイントを構築するために(例えば、 v1 私たちの目の前にある /v1/<endpoint> ）。黙認する. '' それがそうです。
ALLOWED_FILTERS	フィルタリング可能なフィールドリスト。このリスト内のエントリは階層的に動作します。つまりフィルタリングは 'dict.sub_dict.foo' 以下の場合に許可される ALLOWED_FILTERS 以下のいずれかを含む 'dict.sub_dict.foo そして、 'dict.sub_dict' あるいは…。 'dict' それは.逆にフィルタリングは 'dict' 以下の場合に許可される ALLOWED_FILTERS ハム 'dict' それは.設定できるのは [] (フィルタを許可しない)または ['*'] (各フィールドはフィルタの使用を許可する)。あなたのAPIが1つのエンドポイントのみで構成されていない限り、このグローバル設定アプリケーションはオン/オフとして動作し、ローカルレベルで明示的なホワイトリストを委任します(参照 allowed_filters (下記参照)。黙認する. ['*'] それがそうです。 注意してください。 APIキャプチャやDB DoS攻撃が懸念される場合，フィルタをグローバルに無効にし，ローカルレベルの有効なフィルタをホワイトリストに登録することができる.
VALIDATE_FILTERS	リソースアーキテクチャに基づいてフィルタを検証するかどうかを検証する.無効なフィルターは異常を引き起こすだろう。黙認する. False それがそうです。 警告：カスタムルールやタイプを持つフィールドに関するフィルタ式の検証は，性能に大きな影響を与える可能性がある.例えばこのような状況です data_relation -ルールフィールド。フィルタからの重負荷フィールドの除外を考慮する(参照 ALLOWED_FILTERS ）。
SORTING	True ソートがサポートされている場合 GET お願いします、そうでなければ False それがそうです。リソース設定でカバーすることができます。黙認する. True それがそうです。
PAGINATION	True 以下のオブジェクトのためにページを有効にすると GET お願いします、そうでなければ False それがそうです。リソース設定でカバーすることができます。黙認する. True それがそうです。
PAGINATION_LIMIT	QUERY_MAX_RESULTSクエリーパラメータの許容最大値。この制約を超えた値はこの値に暗黙的に置き換えられる.あなたは性能と伝送サイズの間で合理的なトレードオフを達成することを望んでいる。デフォルトは50です。
PAGINATION_DEFAULT	QUERY_MAX_RESULTSのデフォルト値です。デフォルトは25である.
OPTIMIZE_PAGINATION_FOR_SPEED	これを True ページ分け性能を向上させることができます最適化がアクティブ状態にある場合には，データベースに対してカウント操作を行わず，これは大きな集合で遅くなる可能性がある.これには確かにいくつかの結果がある。まず，伝票カウントは返さない.第二に HATEOAS あまり正確ではない：最後のページのリンクがなく、常に次のページのリンクが含まれていて、最後のページでもそうです。大規模な集合では，この機能を開くことで性能を大きく向上させることができる.黙認する. False (性能が遅い)文書数を含む HATEOAS ）。
QUERY_WHERE	フィルタはパラメータのキーを問い合わせる.黙認する. where それがそうです。
QUERY_SORT	クエリーパラメータをソートするキー.黙認する. sort それがそうです。
QUERY_PROJECTION	Projectionsクエリーパラメータの鍵.黙認する. projection それがそうです。
QUERY_PAGE	Pages問合せパラメータの鍵.黙認する. page それがそうです。
QUERY_MAX_RESULTS	最大結果問合せパラメータの鍵.黙認する. max_results それがそうです。
QUERY_EMBEDDED	クエリーパラメータのキーを埋め込む.黙認する. embedded それがそうです。
QUERY_AGGREGATION	クエリーパラメータのキーを集約する.黙認する. aggregate それがそうです。
DATE_FORMAT	日時値を解析して提示するためのPython日付フォーマット。サービス要求時には，一致したJSON文字列が解析されて格納される. datetime 価値観。それに応えて datetime 値は、このフォーマットを使用してJSON文字列として提示されます。RFC 1123(RFC 822を含まない)規格はデフォルトであると考えられる a, %d %b %Y %H:%M:%S GMT (“Tue，2013 Apr 02 10：29：13 GMT”)
RESOURCE_METHODS	資源終端ノードがサポートするHTTPメソッドリスト.許容値： GET そして、 POST そして、 DELETE それがそうです。 POST 挿入に使います。 DELETE 削除します all 資源内容(慎重に有効にしてください)。リソース設定によって書き換えることができます。黙認する. ['GET'] それがそうです。
PUBLIC_METHODS	リソース終端ノードがサポートするHTTPメソッドリストは、 認証と権限 有効になりました。リソース設定でカバーすることができます。黙認する. [] それがそうです。
ITEM_METHODS	項終点がサポートするHTTPメソッドリスト.許容値： GET そして、 PATCH そして、 PUT そして DELETE それがそうです。 PATCH あるいは，パッチをサポートしていないクライアントでは， POST 与 X-HTTP-Method-Override プロジェクト更新のためのテーブルラベル； DELETE 項目削除に使用します。リソース設定によって書き換えることができます。黙認する. ['GET'] それがそうです。
PUBLIC_ITEM_METHODS	項終端がサポートするHTTPメソッドリストは，以下の場合に共通アクセス可能である. 認証と権限 有効になりました。リソース設定でカバーすることができます。黙認する. [] それがそうです。
ALLOWED_ROLES	許容リスト roles リソースエンドポイントに用いられる.リソース設定でカバーすることができます。見 認証と権限 より多くの情報を得ることができます黙認する. [] それがそうです。
ALLOWED_READ_ROLES	許容リスト roles GETおよびOPTIONSメソッドを有するリソース終端ノードのための。リソース設定でカバーすることができます。見 認証と権限 より多くの情報を得ることができます黙認する. [] それがそうです。
ALLOWED_WRITE_ROLES	許容リスト roles POST，PUT，DELETEメソッドを持つリソースエンドノードに対して.リソース設定でカバーすることができます。見 認証と権限 より多くの情報を得ることができます黙認する. [] それがそうです。
ALLOWED_ITEM_ROLES	許容リスト roles プロジェクト最終ノードに使用します。見 認証と権限 より多くの情報を得ることができますリソース設定でカバーすることができます。黙認する. [] それがそうです。
ALLOWED_ITEM_READ_ROLES	許容リスト roles GetおよびOptions手法を持つ項終端ノードのための.見 認証と権限 より多くの情報を得ることができますリソース設定でカバーすることができます。黙認する. [] それがそうです。
ALLOWED_ITEM_WRITE_ROLES	許容リスト roles PUT，PATCH，DELETE手法を持つ項終端ノードのための.見 認証と権限 より多くの情報を得ることができますリソース設定でカバーすることができます。黙認する. [] それがそうです。
ALLOW_OVERRIDE_HTTP_METHOD	グローバル·ヘッダを使用して送信された方法の可能性を有効/無効にする X-HTTP-METHOD-OVERRIDE それがそうです。
CACHE_CONTROL	の価値 Cache-Control サービス時に使用するヘッダフィールド GET 要求(例えば、 max-age=20,must-revalidate ）。API応答にキャッシュコマンドが含まれたくない場合は、それを空にしてください。リソース設定でカバーすることができます。黙認する. '' それがそうです。
CACHE_EXPIRES	の値(秒単位)である. Expires サービス時に使用するヘッダフィールド GET お願いします。非ゼロ値に設定されていれば、いずれにしても CACHE_CONTROL それがそうです。リソース設定でカバーすることができます。デフォルトは0である.
X_DOMAINS	CORS(ドメイン間資源共有)サポート。API保守担当者は、どのドメインがCORS要求を実行することを許可するかを指定することができる許容値は、以下のことを含む。 None ドメインリスト、または '*' 完全にオープンなAPIです黙認する. None それがそうです。
X_DOMAINS_RE	同じ設定と X_DOMAINS ただし，正規表現リストの使用は許可されている.これは，ダイナミックレンジを持つサブドメインのサイトに非常に有用である.正規表現からの正しいアンカーと離脱を確保する.無効な正規表現(例えば '*' )が無視される。黙認する. None それがそうです。
X_HEADERS	CORS(ドメイン間資源共有)サポート。API保守者は、CORS要求と共に送信を許可するヘッダを指定することを許可する。許容値は、以下のことを含む。 None タイトル名リストです。黙認する. None それがそうです。
X_EXPOSE_HEADERS	CORS(ドメイン間資源共有)サポート。API保守担当者は、CORS応答においてどのヘッダを開示するかを指定することを可能にする。許容値は、以下のことを含む。 None タイトル名リストです。黙認する. None それがそうです。
X_ALLOW_CREDENTIALS	CORS(ドメイン間資源共有)サポート。API保守担当者は、クライアントがCookieを送信できるかどうかを指定することができる。唯一許容される値は True 他のどんな内容も無視されるだろう。黙認する. None それがそうです。
X_MAX_AGE	CORS(ドメイン間資源共有)サポート。アクセス制御許可ヘッダの最長期限の設定を許可します。デフォルトは21600です。
LAST_UPDATED	文書の最後の更新日を記録するためのフィールドの名前。このフィールドはEveによって自動的に処理される.黙認する. _updated それがそうです。
DATE_CREATED	文書作成日を記録するためのフィールドの名前。このフィールドはEveによって自動的に処理される.黙認する. _created それがそうです。
ID_FIELD	データベース内のリソース項目を一意に識別するためのフィールドの名前。このフィールドをデータベースに正しくインデックスしたいです。リソース設定でカバーすることができます。黙認する. _id それがそうです。
ITEM_LOOKUP	True プロジェクトエンドポイントがAPI全体で一般的に利用可能でなければならない場合 False そうでなければ。リソース設定でカバーすることができます。黙認する. True それがそうです。
ITEM_LOOKUP_FIELD	リソースエントリを検索する際に使用される文書フィールド。リソース設定でカバーすることができます。黙認する. ID_FIELD それがそうです。
ITEM_URL	デフォルト項目終端ノードURLを構築するためのURLルール.リソース設定でカバーすることができます。デフォルト値. regex("[a-f0-9]{{24}}") どれがMongoDB標準ですか Object_Id フォーマットです。
ITEM_TITLE	XMLとJSONレスポンスに項参照を構築する際に用いるヘッダ.デフォルトでは資源名は，複数‘s’が存在すれば削除する.単一のリソースエンドポイントを構成する際に、カバーされる可能性が高い。
AUTH_FIELD	使 ユーザ制限されたリソースアクセス それがそうです。この機能を有効にすると、ユーザは自分が作成したリソース項目を読み取り/更新/削除することしかできません。キーワードは、リソース項目を作成するユーザIDを格納するためのフィールドの実際の名前を含む。リソース設定でカバーすることができます。黙認する. None これは、この機能を無効にします。
ALLOW_UNKNOWN	いつ？ True このオプションは、任意の未知フィールドを任意のAPIエンドポイントに挿入することを可能にする。気をつけて使ってください。見 未知の事物を許す より多くの情報を得ることができます黙認する. False それがそうです。
PROJECTION	いつ？ True このオプションが有効になります 推算する クローズアップする。リソース設定でカバーすることができます。黙認する. True それがそうです。
EMBEDDING	いつ？ True このオプションが有効になります 組み込み資源序列化 クローズアップする。黙認する. True それがそうです。
BANDWIDTH_SAVER	いつ？ True .POST、PUT、およびPATCH応答は、自動処理のフィールドのみを返す EXTRA_RESPONSE_FIELDS それがそうです。いつ？ False 文書全体が送信される.黙認する. True それがそうです。
EXTRA_RESPONSE_FIELDS	各POST応答と共に提供されるべき追加の文書フィールドリストを構成することを可能にする。通常はフィールドのみを自動処理します (ID_FIELD そして、 LAST_UPDATED そして、 DATE_CREATED そして、 ETAG )は、応答ペイロードに含まれる。リソース設定によって書き換えることができます。黙認する. [] この機能を有効に無効にした。
RATE_LIMIT_GET	GET要求のレート制限を表すタプル.タプルの第1の要素は許容される要求数であり、第2の要素は秒単位の時間ウィンドウである。例えば (300, 60 * 15) 15分ごとに300リクエストの制限が設定されます。黙認する. None それがそうです。
RATE_LIMIT_POST	POST要求レート制限のタプルを表す.タプルの第1の要素は許容される要求数であり、第2の要素は秒単位の時間ウィンドウである。例えば (300, 60 * 15) 15分ごとに300リクエストの制限が設定されます。黙認する. None それがそうです。
RATE_LIMIT_PATCH	パッチ要求のレート制限を表すタプル.タプルの第1の要素は許容される要求数であり、第2の要素は秒単位の時間ウィンドウである。例えば (300, 60 * 15) 15分ごとに300リクエストの制限が設定されます。黙認する. None それがそうです。
RATE_LIMIT_DELETE	削除要求のレート制限を表すタプル.タプルの第1の要素は許容される要求数であり、第2の要素は秒単位の時間ウィンドウである。例えば (300, 60 * 15) 15分ごとに300リクエストの制限が設定されます。黙認する. None それがそうです。
DEBUG	True デバッグモードを有効にするためには、以下の操作を実行してください。 False そうでなければ。
ERROR	ERROR_CODEフィールドのカスタムを許可します。黙認する. _error それがそうです。
HATEOAS	いつ？ False このオプションは無効になります HATEOAS それがそうです。黙認する. True それがそうです。
ISSUES	問題フィールドをカスタマイズすることを可能にする。黙認する. _issues それがそうです。
STATUS	カスタムステータスフィールドを許可します。黙認する. _status それがそうです。
STATUS_OK	データ検証に成功したときに返される状態メッセージ.黙認する. OK それがそうです。
STATUS_ERR	データ検証に失敗した場合は状態メッセージを返す.黙認する. ERR それがそうです。
ITEMS	カスタムアイテムフィールドを許可します。黙認する. _items それがそうです。
META	カスタムメタフィールドを許可します。黙認する. _meta
INFO	文字列値は、EVEホームページ上の所定の情報名を有する情報部(提案値)を含むためのものである _info ）。INFO部分は、API_VERSIONが設定されている場合、EVEサーババージョンおよびAPIバージョンを含む。 None そうでなければ、もしあなたがどんなサーバ情報も公開したくなければ。黙認する. None それがそうです。
LINKS	カスタムリンクフィールドを許可します。黙認する. _links それがそうです。
ETAG	Etagフィールドのカスタムを許可します。黙認する. _etag それがそうです。
IF_MATCH	True 同時制御を有効にするためには False そうでなければ。黙認する. True それがそうです。見 データの完全性と同時制御 それがそうです。
ENFORCE_IF_MATCH	True 同時制御を有効にする際には常に同時制御を強制的に実行するためには， False そうでなければ。黙認する. True それがそうです。見 データの完全性と同時制御 それがそうです。
RENDERERS	有効なレンダラーの変更を許可します。黙認する. ['eve.render.JSONRenderer', 'eve.render.XMLRenderer'] それがそうです。
JSON_SORT_KEYS	True JSONキーを有効にするには False そうでなければ。黙認する. False それがそうです。
JSON_REQUEST_CONTENT_TYPES	サポートされているJSONコンテンツタイプです。サプライヤー固有のJSONタイプをサポートする必要がある場合には非常に有用である。注意してください：返事はまだ基準に従います application/json タイプです。黙認する. ['application/json'] それがそうです。
VALIDATION_ERROR_STATUS	エラーを検証するためのHTTPステータスコード.黙認する. 422 それがそうです。
VERSIONING	以下の場合、ドキュメントバージョン制御を有効にする True それがそうです。リソース設定でカバーすることができます。黙認する. False それがそうです。
VERSIONS	主格納セット名に接尾辞を追加して、文書バージョンを格納するためのシルエット格納セット名を作成する。黙認する. _versions それがそうです。いつ？ VERSIONING 有効にすると集合が現れます myresource_versions データソースは myresource それがそうです。
VERSION_PARAM	文書の特定のバージョンにアクセスするためのURL照会パラメータ。黙認する. version それがそうです。このパラメータを省略して、文書の最新バージョンを取得したり、使用したりする ?version=all `文書のすべてのバージョンのリストを取得する.個々のプロジェクト終端ノードに対してのみ有効である.
VERSION	文書バージョン番号を格納するためのフィールド。黙認する. _version それがそうです。
LATEST_VERSION	文書の最新バージョン番号を格納するためのフィールド。黙認する. _latest_version それがそうです。
VERSION_ID_SUFFIX	シャドウセットには文書IDを格納するために用いられる.黙認する. _document それがそうです。もし ID_FIELD とする. _id この場合、文書IDはフィールドに格納される _id_document それがそうです。
MONGO_URI	A MongoDB URI これは他の配置変数よりも優先的に使用される.
MONGO_HOST	MongoDBサーバアドレス。黙認する. localhost それがそうです。
MONGO_PORT	MongoDBポートです。黙認する. 27017 それがそうです。
MONGO_USERNAME	MongoDBユーザ名。
MONGO_PASSWORD	MongoDBパスワードです。
MONGO_DBNAME	MongoDBデータベース名。
MONGO_OPTIONS	MongoClientクラスに渡すMongoDBキーワードパラメータ __init__ それがそうです。黙認する. {{'connect': True, 'tz_aware': True, 'appname': 'flask_app_name', 'uuidRepresentation': 'standard'}} それがそうです。見 PyMongo mongo_client 参考までに。
MONGO_AUTH_SOURCE	MongoDB許可データベース。黙認する. None それがそうです。
MONGO_AUTH_MECHANISM	MongoDB認証機構.見 PyMongo Authentication Mechanisms それがそうです。黙認する. None それがそうです。
MONGO_AUTH_MECHANISM_PROPERTIES	必要であれば，MongoDBの追加的な認証機構属性を指定する.黙認する. None それがそうです。
MONGO_QUERY_BLACKLIST	リソースフィルタでの使用が許可されていないMongo問合せオペレータのリスト (?where= ）。黙認する. ['$where', '$regex'] それがそうです。 デフォルトでは、攻撃を注入するためのキャリアとして使用される可能性があるため、Mongo JavaScriptオペレータを無効にします。JavaScript問合せも遅いことが多く，通常は(非常に豊富な)Mongo問合せ方言に容易に置き換えることができる.
MONGO_QUERY_WHITELIST	公式に許可されたオペレータリストに加えて、追加のMongo問合せオペレータのリストが許可されます。黙認する. [] それがそうです。 終端ノード(Mongo集合)レベルでカバーすることができる.見 mongo_query_whitelist 下です。
MONGO_WRITE_CONCERN	MongoDB書き込み注目点設定の辞書を定義する.すべての標準書き込み操作設定(w，wtimeout，j，fsync)をサポートします。黙認する. {{'w': 1}} これは、“定期確認書き込み”を意味する(これもMongoのデフォルト設定である)。 ‘w’を2以上に設定するにはコピーをアクティブにする必要があり、そうでなければ500個のエラーが受信されます(書き込みはまだ発生します；Mongoは複数のサーバに書き込まれているかどうかをチェックすることができません)ことに注意してください。 終端ノード(Mongo集合)レベルでカバーすることができる.見 mongo_write_concern 下です。
DOMAIN	APIドメイン定義の辞書を保存する.見 Domain Configuration それがそうです。
EXTENDED_MEDIA_INFO	ファイルアップロードドライバから転送される属性リスト。
RETURN_MEDIA_AS_BASE64_STRING	エンドノード応答へのメディアタイプの埋め込みを制御する.カスタムFlaskエンドポイントのようなバイナリファイルを取得する他の方法がありますが、クライアントがそれを発行/修復することを望む場合には有用です。黙認する. True それがそうです。
RETURN_MEDIA_AS_URL	とする. True 専用メディアエンドポイントでサービスメディアファイルを有効にします。黙認する. False それがそうです。
MEDIA_BASE_URL	以下の場合に使用する基本URL RETURN_MEDIA_AS_URL 活躍しています。結合する. MEDIA_ENDPOINT そして MEDIA_URL メディアファイルが返すURLとして指定します。もし None これがデフォルト値であれば、API基本アドレスを使用します。
MEDIA_ENDPOINT	以下の場合に使用するメディア終端点 RETURN_MEDIA_AS_URL 有効になりました。黙認する. media それがそうです。
MEDIA_URL	専用メディアエンドポイントで提供されるファイルURLのフォーマット。黙認する. regex("[a-f0-9]{{24}}") それがそうです。
MULTIPART_FORM_FIELDS_AS_JSON	もし資源を multipart/form-data すべてのフォーム·データ·フィールドが文字列として提出されます。これは、リソースフィールドに対して実行可能な任意の検証ルールに違反します。提出されたすべてのフォームデータをJSON文字列と見なしたい場合には，この設定を起動しなければならない.この場合、現場検証は正常に作動するだろう。フィールドフォーマットをどのように設定すべきかに関する詳細な情報を読みます メディアファイルに関する注釈は multipart/form-data それがそうです。黙認する. False それがそうです。
AUTO_COLLAPSE_MULTI_KEYS	もし設定が True ，同じキーを用いて複数の値を送信し，使用する. application/x-www-form-urlencoded あるいは…。 multipart/form-data コンテンツタイプは，自動的に値リストに変換される. これと一緒に使うと AUTO_CREATE_LISTS メディアフィールドリストを使用することができる。 黙認する. False
AUTO_CREATE_LISTS	提出非 list タイプのフィールド入力値 list ベリファイアを実行する前に、要素リストを自動的に作成する。 黙認する. False
OPLOG	とする. True 有効にするには 操作日誌 それがそうです。黙認する. False それがそうです。
OPLOG_NAME	これはデータベース集合の名前です 操作日誌 保存されています黙認する. oplog それがそうです。
OPLOG_METHODS	どのような動作を記録すべきHTTPメソッドリスト 操作日誌 それがそうです。黙認する. ['DELETE', 'POST', 'PATCH', 'PUT'] それがそうです。
OPLOG_CHANGE_METHODS	HTTPメソッドリスト，これらの操作にはペアが含まれる. 操作日誌 入る。黙認する. ['DELETE','PATCH', 'PUT'] それがそうです。
OPLOG_ENDPOINT	の名称 操作日誌 端点.このエンドポイントが有効であれば、任意の他のAPIエンドポイントを構成するように構成することができる。とする. None 終端ノードを無効にするためには、以下の操作を実行してください。黙認する. None それがそうです。
OPLOG_AUDIT	とする. True レビュー機能を有効にする場合は、以下の操作を実行してください。レビューを有効にすると、クライアントのIPや文書変更も記録されます 操作日誌 それがそうです。黙認する. True それがそうです。
OPLOG_RETURN_EXTRA_FIELD	有効な場合、オプションの extra フィールドは OPLOG_ENDPOINT それがそうです。黙認する. False それがそうです。
SCHEMA_ENDPOINT	の名称 構造最終ノード それがそうです。黙認する. None それがそうです。
HEADER_TOTAL_COUNT	収集のための応答ペイロード中のアイテム総数を含むカスタムヘッダ GET お願いします。これはあなたにとって便利です HEAD クライアントが項目を知りたい場合の要求カウントは、応答本文を検索することなく。例示的な使用形態は、以下のコマンドを使用して未読投稿のカウントを取得することである where 投稿自体をロードせずに問合せを行う.黙認する. X-Total-Count それがそうです。
JSONP_ARGUMENT	要求にパラメータが設定されている場合、このオプションは、JavaScript関数呼び出しに応答パッケージをもたらす。例えば設定すれば JSON_ARGUMENT = 'callback' 全てのペアが ?callback=funcname 包装をお願いします funcname 電話します。黙認する. None それがそうです。
BULK_ENABLED	設定時に大容量挿入を有効にする True それがそうです。見 一括挿入 より多くの情報を得ることができます黙認する. True それがそうです。
SOFT_DELETE	設定時にソフト削除を有効にする True それがそうです。見 ソフト削除. より多くの情報を得ることができます黙認する. False それがそうです。
DELETED	以下の場合に文書が削除されたか否かを示すフィールド名 SOFT_DELETE 有効になりました。黙認する. _deleted それがそうです。
SHOW_DELETED_PARAM	リソースレベル取得応答にソフト削除項目を含むためのURL照会パラメータ。デフォルトでは‘show_delete’とする.
STANDARD_ERRORS	これは，標準的なAPI応答を提供するHTTPエラーコードリストである.仕様のエラー応答は、実際のエラーコードおよび記述を有するJSON本体を含む。仕様応答を完全に無効にする場合は、空リストに設定してください。黙認する. [400, 401, 403, 404, 405, 406, 409, 410, 412, 422, 428]
VALIDATION_ERROR_AS_LIST	もし True 単一のフィールドエラーであってもリストで返される。デフォルトの場合、単一のフィールドエラーは文字列形式で返され、複数のフィールドエラーは1つのリストにバンドルされる。フィールドのエラー出力を標準化する場合は、これを設定してください True そしてあなたはいつも分野の問題のリストを得るだろう。黙認する. False それがそうです。
UPSERT_ON_PUT	PUT 文書が存在しない場合は，文書の作成を試みる.URLの最終ノードは ID_FIELD 値(もし ID_FIELD ペイロードに含まれており，無視されるであろう).正常検証規則を適用する。応答は 201 Created 成功した創作について。応答ペイロードは、リソースエンドポイントに単一の文書POSTを実行することによって得られる応答ペイロードと同じになる。とする. False この機能を無効にするには、ご利用ください 404 代わりに戻ります。黙認する. True それがそうです。
MERGE_NESTED_DOCUMENTS	もし True 入れ子フィールドの更新は、上の現在のデータとマージされます。 PATCH それがそうです。もし False 更新は、現在のデータを上書きします。黙認する. True それがそうです。
NORMALIZE_DOTTED_FIELDS	もし True 破線フィールドはサブファイルフィールドとして解析と処理を行う.もし False また，破線フィールドは未解析と未処理の状態を保持しており，ペイロードはそのまま下位データ層に渡される.デフォルトのMongoレイヤについては、設定されていますのでご注意ください False 間違いを招きます黙認する. True それがそうです。
NORMALIZE_ON_PATCH	もし True また，パッチ文書はパターンに応じて正規化される.これは、あるフィールドがパッチ本文に含まれていない場合、そのスキームにおけるデフォルト値にリセットされることを意味する。もし False したがって，パッチ本文に含まれないフィールドはそのままである.黙認する. True それがそうです。

ドメイン構成

EVE用語では domain API構造の定義であり，APIを設計し，資源終端点を微調整し，検証ルールを定義する領域である.

DOMAIN これは global configuration setting ：キーがAPIリソースであり、その定義に代入されるPython辞書。

# Here we define two API endpoints, 'people' and 'works', leaving their
# definitions empty.
DOMAIN = {
    'people': {},
    'works': {},
    }

次の2つの部分ではカスタマイズします people 資源です。

リソース/プロジェクト最終ノード

エンドポイントのカスタマイズは主にいくつかをカバーすることで global settings しかし、他の独特な設定も利用可能です。資源設定はつねに小文字である.

url	終端URL。省略すれば DOMAIN DICTはURLを構築するために用いられる.例を挙げてみましょう contacts 使いやすい. people リソースは、以下の位置で取得されることができる： /contacts (ではなく /people ）。URLは、必要に応じて非常に複雑にすることができ、別のAPIエンドポイントに対してネストすることができる(所有することができる /contacts 最後のノード、そして /contacts/overseas 端点.両者は互いに独立して自由に構成可能である). また、正規表現を使用してサブリソースと同様のエンドポイントを設定することができます。見 サブ資源. それがそうです。
allowed_filters	フィルタリング可能なフィールドリスト。このリスト内のエントリは階層的に動作します。つまりフィルタリングは 'dict.sub_dict.foo' 以下の場合に許可される allowed_filters 以下のいずれかを含む 'dict.sub_dict.foo そして、 'dict.sub_dict' あるいは…。 'dict' それは.逆にフィルタリングは 'dict' 以下の場合に許可される allowed_filters ハム 'dict' それは.設定できるのは [] (フィルタは許されない)、または ['*'] (各フィールド上で許可されたフィールド)。黙認する. ['*'] それがそうです。 注意してください。 API捕捉またはDB DoS攻撃が懸念される場合、グローバル無効フィルタ(参照) ALLOWED_FILTERS 上)、そして地方レベルで有効な人をホワイトリストに入れることが可能です。
sorting	True ランキングが有効になれば False そうでなければ。ローカルカバー. SORTING それがそうです。
pagination	True ページを区切って使えば False そうでなければ。ローカルカバー. PAGINATION それがそうです。
resource_methods	資源終端ノードがサポートするHTTPメソッドリスト.許容値： GET そして、 POST そして、 DELETE それがそうです。ローカルカバー. RESOURCE_METHODS それがそうです。 注意してください。 バージョン0.0.5以上のバージョンを実行している場合は、現在サポートされていないものをご利用ください methods キーワードです。
public_methods	リソース終端ノードがサポートするHTTPメソッドリストは、 認証と権限 有効になりました。ローカルカバー. PUBLIC_METHODS それがそうです。
item_methods	項終点がサポートするHTTPメソッドリスト.許容値： GET そして、 PATCH そして、 PUT そして DELETE それがそうです。 PATCH あるいは，パッチをサポートしていないクライアントでは， POST 与 X-HTTP-Method-Override 見出しラベル。ローカルカバー. ITEM_METHODS それがそうです。
public_item_methods	項終点がサポートするHTTPメソッドリストは，以下の場合に公開された公開アクセスを保持する. 認証と権限 有効になりました。ローカルカバー. PUBLIC_ITEM_METHODS それがそうです。
allowed_roles	許容リスト roles リソースエンドノードに用いられています見 認証と権限 より多くの情報を得ることができますローカルカバー. ALLOWED_ROLES それがそうです。
allowed_read_roles	許容リスト roles GETおよびOPTIONSメソッドを有するリソース終端ノードのための。見 認証と権限 より多くの情報を得ることができますローカルカバー. ALLOWED_READ_ROLES それがそうです。
allowed_write_roles	許容リスト roles POST付き資源端点に対しては，PUTとDELETEである.見 認証と権限 より多くの情報を得ることができますローカルカバー. ALLOWED_WRITE_ROLES それがそうです。
allowed_item_read_roles	許容リスト roles GetとOptions手法を持つ項終端ノードに対して.見 認証と権限 より多くの情報を得ることができますローカルカバー. ALLOWED_ITEM_READ_ROLES それがそうです。
allowed_item_write_roles	許容リスト roles PUT，PATH，DELETEメソッドを持つ項終端ノードに対して.見 認証と権限 より多くの情報を得ることができますローカルカバー. ALLOWED_ITEM_WRITE_ROLES それがそうです。
allowed_item_roles	許容リスト roles プロジェクト最終ノードに使用します。見 認証と権限 より多くの情報を得ることができますローカルカバー. ALLOWED_ITEM_ROLES それがそうです。
cache_control	の価値 Cache-Control サービス時に使用するヘッダフィールド GET お願いします。API応答にキャッシュコマンドが含まれたくない場合は、それを空にしてください。ローカルカバー. CACHE_CONTROL それがそうです。
cache_expires	の値(秒単位)である. Expires サービス時に使用するヘッダフィールド GET お願いします。非ゼロ値に設定されていれば、いずれにしても CACHE_CONTROL それがそうです。ローカルカバー. CACHE_EXPIRES それがそうです。
id_field	データベース内のリソース項目を一意に識別するためのフィールド。ローカルカバー. ID_FIELD それがそうです。
item_lookup	True プロジェクトのサイトが利用可能であれば False そうでなければ。ローカルカバー. ITEM_LOOKUP それがそうです。
item_lookup_field	リソースエントリを探す際に使用されるフィールド。ローカルカバー. ITEM_LOOKUP_FIELD それがそうです。
item_url	項終端URLを構造するためのルール.ローカルカバー. ITEM_URL それがそうです。
resource_title	資源リンクを構築する際に用いるヘッダ(HATEOAS).デフォルト資源の url それがそうです。
item_title	XMLとJSONレスポンスに項参照を構築する際に用いるヘッダ.覆う ITEM_TITLE それがそうです。
additional_lookup	デフォルトの標準項終端点を除いて /<resource>/<ID_FIELD_value> 次のように、補助的な読み取り専用終端ノードを定義することができます /<resource>/<person_name> それがそうです。これは2つの項目からなる辞書を定義することで実現できます field そして url それがそうです。前者はルックアップのためのフィールドの名前である.フィールドタイプ(リソースで定義されているような)であれば schema) 文字列でURLルールを入れます url それがそうです。整数であれば省略するだけです url 自動処理されているからですこの機能の用法例については，次のコード片を参照されたい.
datasource	APIリソースをデータベースセットに明示的にリンクする.見 Advanced Datasource Patterns それがそうです。
auth_field	使 ユーザ制限されたリソースアクセス それがそうです。この機能を有効にすると、ユーザは自分が作成したリソース項目を読み取り/更新/削除することしかできません。キーワードは、リソース項目を作成するユーザIDを格納するためのフィールドの実際の名前を含む。ローカルカバー. AUTH_FIELD それがそうです。
allow_unknown	いつ？ True この場合、このオプションは、エンドポイントに任意の未知フィールドを挿入することを可能にする。気をつけて使ってください。ローカルカバー. ALLOW_UNKNOWN それがそうです。見 未知の事物を許す より多くの情報を得ることができます黙認する. False それがそうです。
projection	いつ？ True このオプションが有効になります 推算する クローズアップする。ローカルカバー. PROJECTION それがそうです。黙認する. True それがそうです。
embedding	いつ？ True このオプションは有効になります 組み込み資源序列化 クローズアップする。黙認する. True それがそうです。
extra_response_fields	各POST応答と共に提供されるべき追加の文書フィールドリストを構成することを可能にする。通常はフィールドのみを自動処理します (ID_FIELD そして、 LAST_UPDATED そして、 DATE_CREATED そして、 ETAG )は、応答ペイロードに含まれる。覆う EXTRA_RESPONSE_FIELDS それがそうです。
hateoas	いつ？ False このオプションは無効になります HATEOAS 資源を得る。黙認する. True それがそうです。
mongo_query_whitelist	公式に許可されたオペレータリストに加えて、このエンドポイントで使用される追加のMongoクエリ識別子のリストを許可します。黙認する. [] それがそうです。
mongo_write_concern	端点のデータソースを定義するMongoDBは注目セットの辞書を書く.すべての標準書き込み操作設定(w，wtimeout，j，fsync)をサポートします。黙認する. {{'w': 1}} これは、“定期確認書き込み”を意味する(これもMongoのデフォルト設定である)。 ‘w’を2以上に設定するにはコピーをアクティブにする必要があり、そうでなければ500個のエラーが受信されます(書き込みはまだ発生します；Mongoは複数のサーバに書き込まれているかどうかをチェックすることができません)ことに注意してください。
mongo_prefix	デフォルト設定の上書きを可能にする MONGO プレフィックスは，配置からMongoDB設定を検索する際に用いる. 例えばもし mongo_prefix とする. MONGO2 そして、サイトの要求にサービスを提供する場合には、 MONGO2 プレフィックス設定は、データベースにアクセスするために使用されます。 これは、最終的に、異なるデータベース/サーバからのデータを各エンドポイントで提供することを可能にする。 また会いましょう 認証ドライブのデータベースアクセス それがそうです。
mongo_indexes	アプリケーションを起動する前に、リソースのために作成するインデックスのセットを指定することができます。 インデックスは辞書として表され、キーはインデックス名であり、値は(フィールド、方向)ペアのタプルリストであるか、またはフィールド/方向ペアリストを有するタプルである。 and 辞書として表されるインデックスオプション、例えば {{'index name': [('field', 1)], 'index with args': ([('field', 1)], {{"sparse": True}})}} それがそうです。 マルチペアは、複合インデックスを作成するために使用されます。Directionは、PyMongoによってサポートされるすべてのタイプの値、例えば ASCENDING =1および DESCENDING =-1。すべてのインデックスオプション、例えば sparse そして、 min そして、 max 等支持(参照) PyMongo 文書。) 注意してください。 インデックス設計、作成、保守は非常に重要な課題であり、非常に慎重に計画され、実行されなければならないことを覚えておいてください。一般的に、これはまた非常に資源を消費する操作だ。したがって、このタスクは、APIインスタンス化コンテキストの外で手動で処理することを望むことができるかもしれません。デフォルトの場合、任意の定義変更された既存のインデックスが削除され、再作成されることを覚えておいてください。
authentication	終端ノードの許可論理を持つクラス.提供されていなければ，最終的な汎用authクラス(アプリケーション構造関数パラメータとして渡す)を用いる.認証とライセンスの詳細については、ご参照ください 認証と権限 それがそうです。黙認する. None そして、
embedded_fields	そのフィールドリスト 組み込み資源序列化 デフォルトで有効です。この機能を正常に動作させるためには，リスト中のフィールドは embeddable そして、 embedding 資源に対して活動状態にならなければならない。
query_objectid_as_string	有効化後、Mongo解析器は、オプションの文字列をObjectIdに自動的に変換することを回避します。データベース中の文字列フィールドの値を実際にObjectID値に変換することができるが，ObjectID値に変換すべきでない場合には，これはごく少数の場合に有用である.検索に影響を与えます (?where= )およびペイロードの解析。黙認する. False それがそうです。
internal_resource	いつ？ True このオプションは，資源を内部資源とする.エンドポイント上でいかなるHTTP動作も実行することはできず、そのエンドポイントは依然としてEVEデータ層からアクセス可能である。見 内部資源. より多くの情報を得ることができます黙認する. False それがそうです。
etag_ignore_fields	ETagg値を計算するフィールドリストには適用されない.黙認する. None これは、デフォルトの場合、すべてのフィールドが計算に含まれることを意味する。そのように見える ['field1', 'field2', 'field3.nested_field', ...] それがそうです。
schema	資源が処理している実データ構造の辞書を定義する.データ検証を有効にする。見 Schema Definition それがそうです。
bulk_enabled	いつ？ True このオプションは有効になります 一括挿入 この資源の機能.ローカルカバー. BULK_ENABLED それがそうです。
soft_delete	いつ？ True このオプションは有効になります ソフト削除. この資源の機能.ローカルカバー. SOFT_DELETE それがそうです。
merge_nested_documents	もし True 入れ子フィールドの更新は、上の現在のデータとマージされます。 PATCH それがそうです。もし False 更新は、現在のデータを上書きします。ローカルカバー. MERGE_NESTED_DOCUMENTS それがそうです。
normalize_dotted_fields	もし True 破線フィールドはサブファイルフィールドとして解析と処理を行う.もし False また，破線フィールドは未解析と未処理の状態を保持しており，ペイロードはそのまま下位データ層に渡される.デフォルトのMongoレイヤについては、設定されていますのでご注意ください False 間違いを招きます黙認する. True それがそうです。
normalize_on_patch	もし True また，パッチ文書はパターンに応じて正規化される.これは、あるフィールドがパッチ本文に含まれていない場合、そのスキームにおけるデフォルト値にリセットされることを意味する。もし False したがって，パッチ本文に含まれないフィールドはそのままである.黙認する. True それがそうです。

以下は、主にグローバルAPI設定をカバーすることによって行われるリソースカスタマイズの例である。

people = {
    # 'title' tag used in item links. Defaults to the resource title minus
    # the final, plural 's' (works fine in most cases but not for 'people')
    'item_title': 'person',

    # by default, the standard item entry point is defined as
    # '/people/<ObjectId>/'. We leave it untouched, and we also enable an
    # additional read-only entry point. This way consumers can also perform
    # GET requests at '/people/<lastname>'.
    'additional_lookup': {
        'url': 'regex("[\w]+")',
        'field': 'lastname'
    },

    # We choose to override global cache-control directives for this resource.
    'cache_control': 'max-age=10,must-revalidate',
    'cache_expires': 10,

    # we only allow GET and POST at this resource endpoint.
    'resource_methods': ['GET', 'POST'],
}

構造定義

あなたのAPIが読むだけでない限り、リソースを定義したいかもしれません schemas それがそうです。入力されたストリームの適切な検証を可能にするので、アーキテクチャは重要である。

# 'people' schema definition
schema = {
    'firstname': {
        'type': 'string',
        'minlength': 1,
        'maxlength': 10,
    },
    'lastname': {
        'type': 'string',
        'minlength': 1,
        'maxlength': 15,
        'required': True,
        'unique': True,
    },
    # 'role' is a list, and can only contain values from 'allowed'.
    'role': {
        'type': 'list',
        'allowed': ["author", "contributor", "copy"],
    },
    # An embedded 'strongly-typed' dictionary.
    'location': {
        'type': 'dict',
        'schema': {
            'address': {'type': 'string'},
            'city': {'type': 'string'}
        },
    },
    'born': {
        'type': 'datetime',
    },
}

ご覧のように、モードキーは実際のフィールド名であり、値はフィールド検証ルールを定義する辞書である。許可された検証ルールには：

type	フィールドデータタイプ。以下の1つであってもよい。 string boolean integer float number (整数値および浮動小数点値を許容) datetime dict list media MongoDBデータ層を用いると， objectid そして、 dbref 地理データ構造の使用も許可されています objectid dbref point multipoint linestring multilinestring polygon multipolygon geometrycollection decimal 見 GeoJSON より多くの情報については、地理的地域にアクセスしてください。
required	もし True このフィールドは、挿入時に必須フィールドとなる。
readonly	もし True このフィールドは読みのみである.
minlength, maxlength	許容最小と最大長 string そして list タイプです。
min, max	許容最小値と最大値 integer そして、 float そして number タイプです。
allowed	の許容値リスト string そして list タイプです。
empty	文字列フィールドにのみ適用されます。もし False この値が空であれば，検証は失敗する.黙認する. True それがそうです。
items	属性中の許容値リスト. list 固定長のものは、ご参照ください docs それがそうです。
schema	検証案があります dict タイプと任意の長さ list タイプです。詳細や用法例については、ご参照ください Cerberus documentation それがそうです。
unique	このフィールドの値は、セットにおいて一意でなければならない。 検証制約は，ペイロード文書自体の間で検査を行うのではなく，データベースに対して検査されることに注意されたい.これは、複数の文書ペイロードがあり、2つ以上の文書が‘Unique’制約を設定したフィールドに対して同じ値を搬送する場合、データベースに重複項がないので、ペイロードの検証に成功するという興味深い転換点をもたらす。 これが問題である場合、クライアントは、挿入のために常に1つの文書を送信するか、またはペイロードをAPIに提出する前にローカルに検証することができる。
unique_to_user	このフィールド値は、ユーザに対して一意である。これは以下のような場合に有用である ユーザ制限されたリソースアクセス エンドポイントで有効です。このルールは以下の条件により検証される. ユーザーデータのみ それがそうです。したがって、このシーンでは、異なるユーザによって記憶されている限り、重複が許可される。逆に、単一のユーザは、反復値を格納することができない。 URRAがサイト上でアクティブ状態にない場合，このルールの振舞いは以下のとおりである. unique
unique_within_resource	このフィールドの値は、リソースにおいて一意でなければならない。 これは違います unique 同じフィールド値を持つ文書を検索する際には，データソースフィルタのルールを用いる.リソースが他のリソースとデータベースセットを共有するが、評価フィールドの一意性を評価する際にその文書を考慮すべきでない場合には、このオプションを使用してください。データソースフィルタを持たない資源で使用した場合，このルールの振舞いは以下のとおりである. unique それがそうです。
data_relation	指定値が満たされなければ検証できない引用完全性ルールを許す.これは4つのキーを持つ辞書です resource ：被参照リソースの名前； field ：海外リソース内のフィールド名； embeddable ：に設定する True クライアントは，参照する文書を直列化とともに埋め込むことを要求することができるかどうか.見 組み込み資源序列化 それがそうです。黙認する. False それがそうです。 version ：に設定する True 1つ必要です _version データ関係との関係です見 文書バージョン制御 それがそうです。黙認する. False それがそうです。
nullable	もし True このフィールド値は、 None それがそうです。
default	このフィールドのデフォルト値。POSTおよびPUT要求を処理する際には、欠落フィールドに構成されたデフォルト値を割り当てる。 タイプにも適用されます dict そして list それがそうです。後者は、パターンを有するリストにのみ適用され(リストはランダム数の要素を含み、各要素は dict ） schema = { # Simple default 'title': { 'type': 'string', 'default': 'M.' }, # Default in a dict 'others': { 'type': 'dict', 'schema': { 'code': { 'type': 'integer', 'default': 100 } } }, # Default in a list of dicts 'mylist': { 'type': 'list', 'schema': { 'type': 'dict', 'schema': { 'name': {'type': 'string'}, 'customer': { 'type': 'boolean', 'default': False } } } } }
versioning	以下の場合、ドキュメントバージョン制御を有効にする True それがそうです。黙認する. False それがそうです。
versioned	もし True この場合，このフィールドは文書ごとのバージョン化履歴に含まれる. versioning 有効になりました。黙認する. True それがそうです。
valueschema	全ての値を検証する仕組みです dict それがそうです。辞書は任意のキーを持つことができ，すべてのキーの値は与えられたパターンを用いて検証しなければならない.見 valueschema Cerberus Docsにあります
keyschema	これは valueschema これは判決書のキーワードを検証する。全ての値を検証する仕組みです dict それがそうです。見 keyschema Cerberus Docsにあります
regex	フィールド値が提供された正規表現規則と一致しない場合、検証は失敗する。文字列フィールドにのみ適用されます。見 regex Cerberus Docsにあります
dependencies	この規則は、ターゲットフィールドを許可するために存在しなければならないフィールドリストをリストすることを可能にする。見 dependencies Cerberus Docsにあります
anyof	この規則は、検証に基づいた複数の規則のセットを列挙することができます。フィールドがリスト内の1つのセットに従って検証される場合、フィールドは有効であるとみなされる。見 *of-rules Cerberus Docsにあります
allof	相同 anyof ただし，リスト中のすべてのルール集合は検証しなければならない.
noneof	相同 anyof ただし，リスト中のルール集合を検証する必要はない.
oneof	相同 anyof ただし，リスト中のルール集合は1つだけ検証可能である.
coerce	タイプ強制は、任意の他のベリファイアを実行する前に、呼び出し可能な値をある値に適用することを可能にします。呼び出し可能オブジェクトの返り値は，文書中の新しい値を置き換える.これは、データを検証する前に値を変換するか、またはデータをクリーニングするために使用されて見 value coercion Cerberus Docsにあります

構造文法は Cerberus はい、延長できます。実際イヴ自身は追加することで unique そして data_relation キーワード、そして objectid データタイプです。カスタム検証と用法例に関するより多くの情報は、参照されたい データ検証 それがそうです。

はい。 リソース/プロジェクト最終ノード あなたは自分で定義しました people endpoint. Then, in this section, you defined people validation rules. Now you are ready to update the domain which was originally set up in Domain Configuration ：

# add the schema to the 'people' resource definition
people['schema'] = schema
# update the domain
DOMAIN['people'] = people

高度なデータソースモデル

♪the datasource キーワードは、APIリソースをデータベースセットに明示的にリンクすることを可能にする。省略すると，偽ドメイン資源鍵もデータベース集合の名前である.これは4つの許容キーを持つ辞書です

source	資源が使用するデータベース集合の名前.省略すれば，資源名も有効な集合名であると仮定する.見 複数のAPIエンドポイント、1つのデータソース それがそうです。
filter	データを検索して検証するためのデータベースクエリ。省略すると，デフォルトで集合全体を検索する.見 事前定義されたデータベースフィルタ それがそうです。
projection	終端ノードが公開しているフィールドセット.省略されると、デフォルトの場合、すべてのフィールドがクライアントに返される。見 API終端ノードの公開を制限するフィールドセット それがそうです。
default_sort	終端で検索された文書のデフォルトランキング.省略されると、文書はデフォルトのデータベース順序で返されます。有効な文は以下のようにすべきである. 'datasource': {'default_sort': [('name', 1)]} ランキングとフィルタの詳細については、参照されたい 濾過除去. それがそうです。
aggregation	配管とオプションを集約します。他のすべてのものを使うと datasource 設定は無視されます source それがそうです。終端ノードは読むだけであり、利用可能な項目検索はないだろう。黙認する. None それがそうです。 これは、以下の1つ以上のキーを有する辞書である。 pipeline それがそうです。統合パイプです。文法はPyMongoによって支持された文法と一致しなければならない。より多くの情報については、参照されたい PyMongo Aggregation Examples この役人は MongoDB Aggregation Framework 書類です。 options それがそうです。オプションを集約する。以下の1つまたは複数のキーを有する辞書でなければならない。 allowDiskUse (ブール値) maxTimeMS (整型) batchSize (整型) useCursor (ブール値) 設定するだけでいいです options 何か変更したいなら PyMongo aggregation defaults それがそうです。

事前定義されたデータベースフィルタ

API終端ノードのデータベースフィルタは filter キーワード。

people = {
    'datasource': {
        'filter': {'username': {'$exists': True}}
        }
    }

上の例では people リソースは既存のものを公開し更新するだけで username 現場です。

所定のフィルタは、ユーザクエリ上で実行される(GET要求 where 条項)と標準条件要求 (If-Modified-Since (など)

データソースフィルタは、GET、PATCH、DELETE要求に適用されることに注意されたい。あなたのリソースがPOST要求(文書内挿)を許可する場合、それに応じて検証ルールを設定する必要がある場合があります(私たちの例では、“ユーザ名”は必須フィールドである場合があります)。

静的フィルタと動的フィルタ

所定のフィルターは静的である。あなたはまだ利用できます 事件とリンクする. システム(具体的には on_pre_<METHOD> フック)に動的フィルタを設ける.

複数のAPIエンドポイント、1つのデータソース

複数のAPIエンドポイントは、同一のデータベースセットを指すことができる。例えば、両方を設定することができます /admins そして /users 同じ位置からの読み出しと書き込み people データベース上の集合。

people = {
    'datasource': {
        'source': 'people',
        'filter': {'userlevel': 1}
        }
    }

以上の設定では、検索、編集、削除のみが設定されます people 集合、その中に含まれる userlevel 全部で1つです。

API終端ノードの公開を制限するフィールドセット

デフォルトの場合、GET要求に対するAPI応答は、対応するリソースによって定義されるすべてのフィールドを含む。 schema. ♪the projection 設ける datasource リソースキーワードにより、フィールドセットを再定義することができます。

何かを隠したいときには 秘密フィールド. クライアントでは、投影設定を含み、表示すべきすべてのフィールドを含むことを使用しなければなりません。しかしながら、デフォルト応答をいくつかのフィールドに制限することを望むが、クライアント投影を介してそれらにアクセスすることが依然として許可されている場合、独占投影設定が使用され、除外フィールドは省略されるべきである。

以下に投影設定を含む例を示す.

people = {
    'datasource': {
        'projection': {'username': 1}
        }
    }

以上の設定は公開されます username フィールドは要求を取得するために来ました schema 資源のために定義されている.他のフィールドと できません。 クライアント投影によっても暴露される.以下のAPI呼び出しは返されません lastname あるいは…。 born それがそうです。

$ curl -i http://myapi/people?projection={"lastname": 1, "born": 1}
HTTP/1.1 200 OK

また、API応答からフィールドを除外することができます。しかし今回は排除された分野は はい。はい。 クライアント投影にさらされる.以下に独占投影設定の例を示す.

people = {
    'datasource': {
        'projection': {'username': 0}
        }
    }

以上にはすべての伝票フィールドが含まれますが username それがそうです。ただし，以下のAPI呼び出しは返される. username 今回です。したがって、あなたはこのたびを利用してメディア分野や他の高価な分野にサービスを提供することができます。

ほとんどの場合、投影設定がないか、または投影設定を含むことが好ましい。投影を含むことによって、秘密フィールドはサーバ側から保護され、返されたデフォルトフィールドは、クライアントのショートカット関数によって定義されることができる。

$ curl -i http://myapi/people?projection={"username": 1}
HTTP/1.1 200 OK

POSTおよびPATCH方法は、依然としてアーキテクチャ全体を動作させることが可能であることに留意されたい。例えば、挿入と修正を保護したい場合、この機能は役に立ちます。 認証と権限 プログラムは，同時に読み出しアクセス権限を公衆に開放する.

また見られる.

• 推算する

• 投影を用いたメディアファイルの処理の最適化