http://docs.valence.desire2learn.com/res/course.html#actionsの情報に基づいて、 courseOffering を「更新」するには、いくつかの属性のみを含む CourseOfferingInfo ブロックで PUT を指定することを期待します. これを試すたびに、404 が見つかりません - 成功した GET に同じルートを使用しても (404 は、組織が存在しない、または組織が提供されていないことを示しています - どちらも真実ではありません)。ただし、(前の GET から直接) CreateCourseOffering ブロックを指定すると、PUT は正常に機能します。これは正しく、ドキュメントは間違っていますか? または、このシナリオで他に探すべきものはありますか? ドキュメントには、POST に CreateCourseOffering を使用してオファリングを作成することが記載されています。そのオファリングの 1 つの属性を更新したいだけなので、PUT が最適だと考えました。
1 に答える
0
ブロックで「作成」POST ルートを使用するCreateCourseOfferingと、新しいコース オファリングが作成され、新しく作成されたコース オファリングの CourseOffering ブロックが返されます (これには、作成した新しい組織ユニットの組織ユニット ID 値が含まれます)。建てられた）。
既存のコース オファリングを更新する場合は、ご想像のとおり、 "update" PUT ルートをCourseOfferingInfoブロックと共に使用する必要があります。このブロックのすべてのフィールドに有効な情報を提供する必要があることに注意してください。これが正常に使用されると、LMS はそのブロックで指定したすべてのプロパティを組織単位の新しい値として使用するためです。StartDateおよびEndDateフィールドは特に注意が必要です。フィールドが適用できない場合は、有効な値 (これらの値の 3 桁のミリ秒指定子が必須であることに注意してください)またはJSON値のいずれかを指定する必要があります。UTCDateTimenull
なんで404？404 と渡されたデータで見られることは、バックエンド サービスがデータ バインディングを行う方法にある可能性があります。提供された JSON データ (およびクエリ パラメーター) を読み取り/操作できるデータ オブジェクトに逆シリアル化しようとします。予期されるプロパティのスーパーセットを含む JSON ブロックを提供すると、これが機能する可能性があります (たとえば、提供するCourseOfferingことが期待されているときにブロックを提供するCourseOfferingInfo) バインディング レイヤーは必要のないフィールドを無視する可能性があるためです。予期されるデータ型にバインドできないプロパティの値を指定したため、または期待される JSON プロパティ フィールドを指定しなかったために、バインド プロセスが失敗した場合、サービスが 404 (パラメーター化された受信データのバインド/シリアル化解除は、URL ルートを基になるサービス ハンドラーに一致させると同時に行われるためです)。
Web サービスが期待されるデータ オブジェクトにバインドできるJSON 構造 (およびクエリ パラメーター) を提供しても、提供する値が無効または無意味である場合、これにより、基になるサービス ハンドラーが 400 で応答する可能性があります (無効なリクエスト）。ただし、ここまで到達するには、パラメーター化されたデータを適切に逆シリアル化し、基になるサービスが検査できるようにデータ オブジェクトにバインドする必要があります。
この事実をより明確に引き出すために、ドキュメントを更新する予定です。呼び出し元のクライアントの観点から見た最も安全なポリシーは、個々のルートが期待するものとまったく同じ有効な JSON 構造を渡すことです。これは、特に基になるバックエンド サービスの実装によって受信要求の処理方法が変更される可能性があるためです。
于 2014-01-03T20:14:43.610 に答える