المعاملات في بقية ؟

Question

أنا أتساءل كيف كنت تنفذ الاستخدام التالية-في حالة الراحة.هل من الممكن أن تفعل دون المساس المفاهيمي النموذج ؟

قراءة أو تحديث موارد متعددة في نطاق صفقة واحدة.على سبيل المثال ، نقل 100 دولار من بوب حساب مصرفي في جون الحساب.

بقدر ما أستطيع أن أقول, الطريقة الوحيدة لتنفيذ ذلك هي عن طريق الغش.يمكنك أن وظيفة الموارد المرتبطة إما جون أو بوب تنفيذ العملية بأكملها باستخدام معاملة واحدة.بقدر ما أنا قلق من هذا يكسر بقية العمارة لأنك أساسا نفق وهو استدعاء RPC من خلال وظيفة بدلا من التشغيل على الموارد الفردية.

Answer 1

النظر في راحة سلة التسوق السيناريو.سلة التسوق هو المفهوم معاملتك المجمع.في نفس الطريقة التي يمكنك إضافة عدة عناصر إلى سلة التسوق ومن ثم تقديم تلك السلة في معالجة الأمر ، يمكنك إضافة بوب حساب دخول الصفقة المجمع ثم فاتورة حساب الدخول إلى المجمع.عندما تكون جميع القطع في المكان ثم يمكنك إضافة/وضع الصفقة المجمع مع جميع القطع المكونة.

Answer 2

هناك عدد قليل من القضايا الهامة التي ليست الإجابة على هذا السؤال ، والتي أعتقد أنها سيئة للغاية ، لأنه يحتوي على نسبة عالية الترتيب في جوجل عن مصطلحات البحث :-)

على وجه التحديد, لطيفة propertly ليكون:إذا قمت بنشر مرتين (لأن بعض ذاكرة التخزين المؤقت hiccupped في المتوسط) يجب عدم تحويل المبلغ مرتين.

للوصول الى هذا, يمكنك إنشاء المعاملة ككائن.هذا يمكن أن تحتوي على جميع البيانات تعرف بالفعل ، ووضع الصفقة في حالة معلقة.

POST /transfer/txn
{"source":"john's account", "destination":"bob's account", "amount":10}

{"id":"/transfer/txn/12345", "state":"pending", "source":...}

وبمجرد الانتهاء من هذه الصفقة ، يمكنك ارتكابها ، شيء من هذا القبيل:

PUT /transfer/txn/12345
{"id":"/transfer/txn/12345", "state":"committed", ...}

{"id":"/transfer/txn/12345", "state":"committed", ...}

علما بأن متعددة يضع لا يهم في هذه النقطة ؛ حتى تحصل على txn سيعود الوضع الحالي.على وجه التحديد, ثاني شأن هذا الكشف أن الأولى كانت في الدولة ، و يعود ذلك -- أو إذا كنت في محاولة لوضعها في "rolledback" الدولة بعد ذلك بالفعل في "ملتزمة" الدولة وسوف تحصل على خطأ الفعلية التي ارتكبت الحركة مرة أخرى.

طالما أنك تتحدث إلى واحد أو قاعدة بيانات أو قاعدة بيانات متكاملة الصفقة رصد هذه الآلية سوف تعمل في الواقع على ما يرام.قد بالإضافة إلى ذلك يعرض المهلات المعاملات التي تستطيع حتى التعبير عن استخدام تنتهي رؤوس إذا أردت.

Answer 3

في بقية الشروط ، الموارد هي الأسماء التي يمكن أن تصرف على الخام (إنشاء/قراءة/تحديث/حذف/) الأفعال.حيث لا يوجد "تحويل الأموال" الفعل, ونحن بحاجة إلى تعريف "الصفقة" الموارد التي يمكن أن تصرف على الخام.هنا مثال في HTTP+جدري.الخطوة الأولى هي إنشاء (HTTP POST طريقة) جديد فارغة المعاملات:

POST /transaction

هذا بإرجاع معرف المعاملة ، على سبيل المثال"1234" وفقا URL "/المعاملات/1234".علما أن إطلاق هذا المنصب عدة مرات لن يخلق نفس المعاملة مع عدة معرفات كما يتجنب إدخال "معلقة".أيضا, بعد لا يمكن أن يكون دائما idempotent (بقية الشرط) ، لذلك فمن عادة الممارسات الجيدة للحد من البيانات في المشاركات.

يمكنك ترك جيل من رقم المعاملات تصل إلى العميل.في هذه الحالة, أن وظيفة /المعاملات/1234 لإنشاء حركة "1234" و الملقم بإرجاع خطأ إذا كانت موجودة بالفعل.في خطأ استجابة الملقم العودة حاليا غير مستخدمة ID المناسبة URL.انها ليست فكرة جيدة الاستعلام عن ملقم معرف جديد مع طريقة الحصول عليها ، منذ الحصول ينبغي أبدا تغيير الخادم الدولة ، وخلق/حجز معرف جديد من شأنه أن يغير الخادم الدولة.

التالي التحديث (ضع HTTP طريقة) المعاملة مع جميع البيانات ضمنيا بارتكابه:

PUT /transaction/1234
<transaction>
  <from>/account/john</from>
  <to>/account/bob</to>
  <amount>100</amount>
</transaction>

إذا كانت الصفقة مع ID "1234" وضعت من قبل الملقم يعطي استجابة خطأ ، وإلا موافق استجابة URL لعرض الانتهاء من الصفقة.

ملحوظة::في /حساب/ " جون " "جون" ينبغي أن يكون حقا جون فريدة من نوعها رقم الحساب.

Answer 4

السؤال الباقي هو الغالب أوضح مع قاعدة البيانات-مثل الأمثلة ، حيث هناك شيئا المخزنة, تحديث, استرجاعها, حذف.هناك بعض الأمثلة مثل هذا واحد ، حيث server هو من المفترض أن معالجة البيانات في بعض الطريق.لا أعتقد روي إيفاد إدراج أي في أطروحته ، الذي يستند إلى http بعد كل شيء.

لكنه تحدث عن "التمثيلية نقل الدولة" كدولة آلة, مع روابط الانتقال إلى الدولة القادمة.في هذه الطريقة ، الوثائق (تمثيل) تتبع العميل الدولة, بدلا من الخادم الاضطرار إلى القيام بذلك.في هذه الطريقة, لا يوجد عميل الدولة, الدولة الوحيدة في الشروط من الرابط الذي في.

لقد تم التفكير في هذا ، يبدو لي معقولا أن الحصول على الملقم لمعالجة شيء لك عند تحميل الملقم تلقائيا إنشاء الموارد ذات الصلة ، وتعطيك روابط لهم (في الواقع, لن تحتاج إلى إنشاء تلقائيا لهم:يمكن أن أقول لك الروابط و خلق لهم عندما وإذا كنت تتبع لهم - كسول الخلق).و أيضا تعطيك روابط خلق جديد ذات الموارد - الموارد ذات الصلة نفس URI ولكن أطول (يضيف لاحقة).على سبيل المثال:

1. يمكنك تحميل (بعد) تمثيل مفهوم المعاملة مع جميع المعلومات. هذا يبدو تماما مثل استدعاء RPC, لكنه حقا خلق "الصفقة المقترحة من الموارد".هـ.ز URI: /transaction مواطن الخلل سوف يسبب العديد من هذه الموارد سيتم إنشاؤها مع كل مختلف URI.
2. استجابة الملقم الدول التي تم إنشاؤها مورد URI ، التمثيل - ويشمل هذا الرابط (URI) خلق من الموارد ذات الصلة من جديد "الصفقة التي ارتكبت الموارد". والموارد الأخرى ذات الصلة هي رابط حذف الصفقة المقترحة.هذه هي الولايات في الدولة-آلة التي يمكن للعميل متابعة.منطقيا, هذه هي جزء من الموارد التي تم إنشاؤها على الملقم بعد معلومات العميل الموردة.هـ.ز محددات: /transaction/1234/proposed, /transaction/1234/committed
3. لك بعد على الرابط إنشاء "الصفقة التي ارتكبت الموارد", الذي يخلق هذا المورد, تغيير الدولة من الخادم (أرصدة الحسابات اثنين)**.بحكم طبيعة هذه الموارد لا يمكن أن يتحقق إلا مرة واحدة و لا يمكن تحديث.ولذلك مواطن الخلل ارتكاب العديد من المعاملات لا يمكن أن تحدث.
4. يمكنك الحصول على تلك الموارد اثنين ، لمعرفة ما الدولة.على افتراض أن وظيفة يمكن تغيير الموارد الأخرى الاقتراح الآن علامة على أنها "ملتزمة" (أو ربما لا تتوفر في جميع).

هذا هو مماثل لكيفية صفحات الويب تعمل النهائي صفحة ويب قائلا "هل أنت متأكد من أنك تريد أن تفعل هذا؟" النهائية صفحة ويب هو نفسه تمثيل الدولة الصفقة التي تتضمن وصلة للذهاب إلى الدولة القادمة.ليس فقط في المعاملات المالية ؛ أيضا (على سبيل المثال) معاينة ثم لارتكاب على ويكيبيديا.أعتقد أن الفرق في الراحة هو أن كل مرحلة في تسلسل الدول صريح اسم (لها URI).

في الحياة الحقيقية المعاملات/المبيعات ، غالبا ما تكون هناك البدنية المختلفة وثائق مراحل مختلفة من المعاملة (اقتراح, طلب شراء واستلام الخ).حتى أكثر من أجل شراء منزل ، مع تسوية الخ.

OTOH هذا يشعر وكأنه يلعب مع دلالات لي ، أنا غير مرتاح مع nominalization تحويل الأفعال إلى الأسماء لجعلها مريحة, "لأنه يستخدم الأسماء (محددات) بدلا من الأفعال (استدعاءات RPC)".أياسم "الصفقة التي ارتكبت الموارد" بدلا من الفعل "ارتكاب هذه الصفقة".اعتقد ميزة واحدة من nominalization يمكنك الرجوع إلى الموارد بالاسم بدلا من الحاجة إلى تحديد ذلك بطريقة أخرى (مثل الحفاظ على حالة جلسة العمل ، حتى تعرف ما "هذه" الصفقة...)

ولكن السؤال المهم هو:ما هي الفوائد من هذا النهج ؟ أيما هي الطريقة بقية هذا النمط أفضل من RPC-النمط ؟ هي تقنية رائعة لكل صفحات الويب أيضا مفيدة في معالجة المعلومات, خارج متجر/استرداد/تحديث/حذف ؟ أعتقد أن مفتاح الاستفادة من بقية التدرجية ؛ جانبا واحدا من ذلك لا تحتاج إلى الحفاظ على العميل الدولة صراحة (ولكن مما يجعل الضمني في URI من الموارد التالية الدول الروابط في التمثيل).في هذا المعنى أن يساعد.ولعل هذا يساعد في طبقات/pipelining أيضا ؟ OTOH فقط مستخدم واحد سوف ننظر في الصفقة, لذلك ليس هناك أي ميزة في التخزين المؤقت بحيث يمكن للآخرين قراءتها فوز كبير على http.

Answer 5

إذا كنت تقف إلى تلخيص المناقشة هنا ، فإنه من الواضح جدا أن بقية ليس من المناسب للعديد من واجهات برمجة التطبيقات ، خاصة عندما يكون العميل-الخادم التفاعل هو جليل بطبيعتها, كما هو الحال مع غير تافهة المعاملات.لماذا القفز من خلال الأطواق كل واقترح العميل والخادم على حد سواء ، من أجل pedantically اتباع بعض المبدأ الذي لا يصلح المشكلة ؟ أفضل مبدأ إعطاء العميل أسهل وأكثر طبيعية ومنتجة طريقة يؤلف مع التطبيق.

باختصار, إذا كنت حقا تفعل الكثير من المعاملات (أنواع الحالات لا) في التطبيق الخاص بك, كنت حقا لا ينبغي أن يكون خلق RESTful API.

Answer 6

يجب أن لفة الخاص بك "معرف المعاملة" نوع من تكساس الإدارة.لذلك سيكون 4 مكالمات:

http://service/transaction (some sort of tx request)
http://service/bankaccount/bob (give tx id)
http://service/bankaccount/john (give tx id)
http://service/transaction (request to commit)

سيكون لديك للتعامل مع تخزين الإجراءات في ديسيبل (إذا متوازنة التحميل) أو في الذاكرة أو تلك ، ثم التعامل مع ارتكاب التراجع المهلة.

لا راحة يوم في الحديقة.

Answer 7

لقد جنحت بعيدا عن هذا الموضوع لمدة 10 سنوات.العودة, لا أصدق الدين يتنكر العلم أنك في واد عند جوجل بقية+موثوقة.الارتباك هو أسطوري.

وأود أن تقسيم هذه العريضة السؤال إلى ثلاثة:

• خدمات المصب.أي خدمة ويب يمكنك تطوير سوف يكون المصب الخدمات التي تستخدمها ، والذي الصفقة الجملة لا يوجد لديك خيار سوى أن تتبع.يجب أن تحاول إخفاء كل هذا من مستخدمي الخدمة الخاص بك ، تأكد من أن جميع أجزاء العملية تنجح أو تفشل كمجموعة ، ثم تعود هذه النتيجة إلى المستخدمين.
• الخدمات الخاصة بك.عملاء يريدون لبس فيها النتائج إلى شبكة الإنترنت خدمة المكالمات و المعتاد بقية نمط من صنع آخر, وضع أو حذف الطلبات مباشرة على الموضوعية الموارد الضربات لي الفقراء ، وسهولة تحسين طريقة تقديم هذا اليقين.إذا كنت الرعاية حول موثوقية ، تحتاج إلى تحديد إجراءات الطلبات.هذا الرقم يمكن أن يكون guid التي تم إنشاؤها على العميل ، أو البذور قيمة من relational DB على الملقم, لا يهم.الملقم إنشاء معرف طلب الرد هو مخصص لتبادل الهوية.إذا لم ينجح هذا الطلب أو نصف نجاح أي مشكلة العميل فقط يكرر الطلب.غير المستخدمة معرفات لا ضرر ولا ضرار.
  
  هذا مهم لأنه يتيح جميع الطلبات اللاحقة بالكامل idempotent ، بمعنى أنه إذا كانت تتكرر مرات n عودتهم نفس النتيجة و السبب شيء آخر يحدث.الخادم يخزن كل الردود ضد id العمل ، إذا كان يرى نفس الطلب ، الاعادة نفس الاستجابة.أكمل العلاج من هذا النمط في هذه google doc.وثيقة تشير إلى تنفيذ ذلك ، وأعتقد(!), عموما يلي بقية مديري المدارس.خبراء بالتأكيد سوف تقول لي كيف أنه ينتهك الآخرين.هذا النمط يمكن أن يكون من المفيد توظيف أي حد الدعوة إلى الويب الخاص بك خدمة ما إذا كان أو لم يكن هناك المصب المعاملات المعنية.
• دمج الخدمة في "المعاملات" التي تسيطر عليها المنبع الخدمات.في سياق خدمات الويب الكاملة حمض المعاملات تعتبر عادة لا يستحق كل هذا الجهد, ولكن يمكنك أن تساعد إلى حد كبير على المستهلكين من خلال توفير إلغاء و/أو تأكيد الروابط في رسالة تأكيد الحجز الاستجابة ، وبالتالي تحقيق المعاملات عن طريق التعويض.

الشرط الخاص بك هو أساسي.لا تدع الناس يقولون لك الحل الخاص بك هو غير مباح.الحكم على أبنية في ضوء مدى ، وكيف ببساطة وهي تعالج المشكلة.

Answer 8

أولا نقل المال هو شيء أن كنت لا تستطيع أن تفعل في مورد واحد المكالمة.الإجراء الذي تريد القيام به هو ارسال المال.لذا يمكنك إضافة المال نقل الموارد إلى حساب المرسل.

POST: accounts/alice, new Transfer {target:"BOB", abmount:100, currency:"CHF"}.

القيام به.أنت لست بحاجة إلى أن تعرف أن هذه هي الصفقة التي يجب أن تكون الذرية وما إلى ذلك.يمكنك فقط نقل المال الملقب.إرسال الأموال من أ إلى ب.

---

ولكن في حالات نادرة هنا حل عام:

إذا كنت تريد أن تفعل شيئا معقدة للغاية تنطوي على العديد من الموارد في مجموعة محددة السياق مع الكثير من القيود التي في الواقع عبر ما مقابللماذا حاجز (الأعمال مقابلتنفيذ المعرفة) تحتاج إلى نقل الدولة.منذ يجب أن يكون بقية عديمي الجنسية لك كعميل تحتاج إلى نقل الدولة في جميع أنحاء.

إذا قمت بنقل الدولة تحتاج إلى إخفاء المعلومات داخل من العميل.لا يجب على العميل معرفة المعلومات الداخلية فقط التي يحتاجها تنفيذ ولكنها لا تحمل المعلومات ذات الصلة في مجال الأعمال التجارية.إذا كانت هذه المعلومات لا قيمة الدولة يجب أن تكون مشفرة ولا كناية مثل رمزية ، تمر أو شيء تحتاج إلى استخدامها.

هذه طريقة واحدة يمكن أن تمر الحالة الداخلية حول استخدام التشفير و التوقيع على نظام يمكن أن تكون لا تزال آمنة وسليمة.العثور على الحق في التجريد للعميل لماذا كان يمر حول الدولة المعلومات هو أمر متروك التصميم والهندسة المعمارية.

---

الحل الحقيقي:

تذكر بقية الحديث HTTP HTTP يأتي مع مفهوم استخدام ملفات تعريف الارتباط.هذه ملفات تعريف الارتباط غالبا ما تكون منسية عندما يتحدث الناس عن بقية API و سير العمل و التفاعلات التي تغطي موارد متعددة أو طلبات.

تذكر ما هو مكتوب في ويكيبيديا عن ملفات تعريف الارتباط HTTP:

ملفات تعريف الارتباط تم تصميمه ليكون آلية موثوقة المواقع تذكر جليل المعلومات (مثل البنود في عربة التسوق) أو إلى سجل التصفح الخاص بالمستخدم النشاط (بما في ذلك النقر خاصة أزرار تسجيل الدخول أو تسجيل الصفحات التي تمت زيارتها من قبل المستخدم بقدر ما يعود إلى أشهر أو سنوات).

ذلك أساسا إذا كنت تحتاج إلى تمرير على الدولة استخدام ملف تعريف الارتباط.وهي مصممة بالضبط نفس السبب ، فمن HTTP وبالتالي فإنه متوافق مع بقية التصميم :).

---

الحل الأفضل:

إذا كنت تتحدث عن العميل إجراء سير العمل التي تنطوي على طلبات متعددة عادة ما نتحدث عن البروتوكول.كل شكل من البروتوكول يأتي مع مجموعة من الشروط المسبقة لكل المحتملة خطوة مثل أداء خطوة قبل أن يمكنك أن تفعل بي

وهذا أمر طبيعي ولكن فضح بروتوكول العملاء يجعل كل شيء أكثر تعقيدا.من أجل تجنب ذلك مجرد التفكير في ما نقوم به عندما يكون لدينا للقيام التفاعلات المعقدة و الأشياء في العالم الحقيقي....نحن نستخدم عامل.

باستخدام عامل استعارة يمكنك توفير الموارد التي يمكن أن تؤدي جميع الخطوات اللازمة لك متجر التخصيص الفعلي / تعليمات انها تتصرف على قائمة (حتى نتمكن من استخدام وظيفة على الوكيل أو 'وكالة').

مجمع سبيل المثال:

شراء منزل:

تحتاج إلى إثبات مصداقية الخاصة بك (مثل توفير الشرطة الخاصة بك إدخالات السجل), تحتاج إلى التأكد من التفاصيل المالية ، تحتاج إلى شراء المنزل الفعلي باستخدام محام طرف ثالث موثوق به تخزين الأموال ، تحقق من أن البيت ملك لك و إضافة شراء الأشياء الخاصة بك سجلات الضرائب وما إلى ذلك.(تماما كما على سبيل المثال ، بعض الخطوات قد تكون خاطئة أو أيا كان).

هذه الخطوات قد تستغرق عدة أيام إلى أن تكتمل بعض يمكن أن يتم بالتوازي.... الخ

من أجل القيام بذلك, يمكنك فقط إعطاء العميل مهمة شراء المنزل مثل:

POST: agency.com/ { task: "buy house", target:"link:toHouse", credibilities:"IamMe"}.

القيام به.وكالة يرسل لك مرة أخرى إشارة إلى أنك يمكن أن تستخدم لمعرفة وتتبع حالة من هذا العمل و الباقي يتم تلقائيا من قبل وكلاء من الوكالة.

التفكير في تعقب علة على سبيل المثال.أساسا لديك تقرير الشوائب و يمكن استخدام علة id للتحقق من ما يحدث.يمكنك حتى استخدام خدمة الاستماع إلى تغييرات من هذا المورد.مهمة القيام به.

Answer 9

أعتقد أنه في هذه الحالة هو مقبول تماما لكسر نظرية خالصة من الراحة في هذه الحالة.في أي حال, أنا لا أعتقد أن هناك أي شيء في الواقع في بقية أن يقول لا يمكنك لمس الكائنات تعتمد في الحالات التي تتطلب ذلك.

أعتقد أنه لا يستحق إضافية الأطواق يمكنك القفز من خلال إنشاء مخصص إدارة المعاملات ، عندما يمكنك فقط الاستفادة من قاعدة البيانات للقيام بذلك.

Answer 10

يجب عدم استخدام الخادم جانب المعاملات في بقية.

واحد من بقية contraints:

عديمي الجنسية

ملقم–عميل الاتصالات مزيدا من الضغوط من قبل أي عميل السياق يجري تخزينها على الخادم بين الطلبات.كل طلب من أي عميل يحتوي على كافة المعلومات اللازمة لخدمة الطلب ، أي جلسة هو العميل.

فقط راحة طريقة لإنشاء معاملة إعادة تسجيل ووضعها في العميل الدولة.مع طلبات العميل يرسل إعادة تسجيل الملقم redoes الصفقة ،

1. لفات الصفقة مرة أخرى ولكن يوفر معاملة جديدة redo log (خطوة واحدة أبعد من ذلك)
2. أو أخيرا في إتمام الصفقة.

ولكن ربما هو أسهل لاستخدام جلسة عمل ملقم القائمة على التكنولوجيا التي تدعم جانب الخادم المعاملات.

Answer 11

أعتقد أن ذلك سيكون في حالة استخدام معرف فريد تم إنشاؤه على العميل للتأكد من أن اتصال زوبعة لا يعني في النفاق حفظها من قبل API.

أعتقد أن استخدام عميل إنشاء GUID الحقل جنبا إلى جنب مع نقل موضوع ضمان نفس المعرف الفريد العمومي لا إعادة إدخالها مرة أخرى سيكون أبسط حل التحويل المصرفي المسألة.

لا أعرف عن سيناريوهات أكثر تعقيدا ، مثل العديد من تذاكر الطيران حجز أو أبنية صغيرة.

لقد وجدت ورقة حول هذا الموضوع ، المتعلقة تجارب التعامل مع الصفقة atomicity في خدمات مريحة.

Answer 12

في الحالة البسيطة (بدون توزيع الموارد) ، يمكن النظر في المعاملة مثل الموارد ، حيث فعل خلق فإنه يبلغ الغاية.

لذا نقل بين <url-base>/account/a و <url-base>/account/b, هل يمكن المشاركة التالية <url-base>/transfer.

<transfer>
    <from><url-base>/account/a</from>
    <to><url-base>/account/b</to>
    <amount>50</amount>
</transfer>

وهذا من شأنه خلق جديد نقل الموارد والعودة الجديد رابط نقل - على سبيل المثال <url-base>/transfer/256.

في لحظة نجاح آخر ، ثم 'الحقيقية' الصفقة نفذت على الخادم ، كمية إزالتها من حساب واحد ، إضافة إلى آخر.

غير أن هذا لا يغطي المعاملات الموزعة (إذا قلت 'a' هو الذي عقد في بنك واحد وراء واحد الخدمة ، و 'ب' يقام في بنك آخر وراء خدمة أخرى) - غير القول "محاولة العبارة جميع العمليات في الطرق التي لا تتطلب المعاملات الموزعة".

Answer 13

أعتقد أنك يمكن أن تشمل تان في عنوان/الموارد:

1. ضع /المعاملات للحصول على معرف (على سبيل المثال"1")
2. [يضع, على, بعد, أيا كان] /1/حساب/بوب
3. [يضع, على, بعد, أيا كان] /1/حساب/بيل
4. حذف /المعاملة مع معرف 1

مجرد فكرة.