संशोधन (Revisions)

JSON:API मॉड्यूल entity revisions को resource versions के रूप में एक्सपोज़ करता है, जो RFC5829: Link Relation Types for Simple Version Navigation between Web Resources से प्रेरित है।

वर्तमान सीमाएँ:

• Resource versions (entity revisions) केवल पढ़े जा सकते हैं। और केवल Node और Media entity प्रकारों (node--* और media--* resource प्रकारों) के लिए ही JSON:API resource versions को सुलभ बना सकता है (क्योंकि Drupal core में अभी कोई औपचारिक entity revision access control API नहीं है। जैसे ही यह उपलब्ध होगा, हम सभी revisionable entity प्रकारों को JSON:API के माध्यम से उपलब्ध कराएँगे। देखें #3031271: किसी भी entity प्रकार के लिए version negotiation का समर्थन करें (वर्तमान में केवल Node और Media समर्थित हैं)).
• हालाँकि, resource versions स्वतः बन जाते हैं जब किसी resource प्रकार (entity type + bundle) को PATCH किया जाता है जो स्वचालित रूप से नए versions (revisions) बनाने के लिए कॉन्फ़िगर होता है। हम इस पर काम कर रहे हैं कि versionable resource पर एक PATCH अनुरोध यह निर्दिष्ट कर सके कि नया revision बनाया जाना चाहिए या नहीं। देखें #2993557: JSON:API के माध्यम से autosave कार्यक्षमता का समर्थन करने के लिए revisionable entities को PATCH करते समय नए revision के वैकल्पिक निर्माण की अनुमति दें।.

Revision समर्थन JSON:API स्पेसिफिकेशन का आधिकारिक हिस्सा नहीं है। हालाँकि, कई "प्रोफाइल्स" विकसित की जा रही हैं (यह भी स्पेक का आधिकारिक हिस्सा नहीं हैं, लेकिन पहले से JSON:API v1.1 में शामिल हैं) ताकि किसी भी कस्टम व्यवहार को मानकीकृत किया जा सके जो JSON:API मॉड्यूल ने विकसित किया है (जो अभी भी स्पेसिफिकेशन अनुरूप हैं)।

ऐसा करने से, JSON:API मॉड्यूल अन्य सिस्टम्स के साथ अधिकतम संगत होना चाहिए और "Drupalisms" को न्यूनतम करना चाहिए जिन्हें JSON:API इम्प्लीमेंटेशन के खिलाफ निर्माण करने वाले डेवलपर को जानने की आवश्यकता होगी।

JSON:API मॉड्यूल में "version" वह कोई भी revision है जो पहले, या वर्तमान में, डिफ़ॉल्ट revision रहा है। सभी revisions को "version" नहीं माना जाता। जो revisions "default" revision के रूप में चिह्नित नहीं होते, उन्हें "working copies" माना जाता है क्योंकि वे आमतौर पर सार्वजनिक रूप से उपलब्ध नहीं होते और वे revisions होते हैं जिन पर अधिकांश नया कार्य लागू किया जाता है।

जब Content Moderation मॉड्यूल इंस्टॉल किया जाता है, तो यह संभव है कि नवीनतम डिफ़ॉल्ट revision *सबसे नवीनतम* revision न हो।

किसी resource version को अनुरोध करना URL क्वेरी पैरामीटर के माध्यम से किया जाता है। इसका निम्नलिखित रूप होता है:

            version-identifier
                  __|__
                 /     \
?resourceVersion=foo:bar
                 \_/ \_/
                  |   |
  version-negotiator  |
              version-argument

एक version identifier एक स्ट्रिंग है जिसमें किसी विशेष revision को लोड करने के लिए पर्याप्त जानकारी होती है। version negotiator कॉम्पोनेंट उस negotiation मैकेनिज़्म का नाम बताता है जो revision लोड करने के लिए उपयोग होता है। वर्तमान में, यह या तो id या rel हो सकता है। id negotiator एक version argument लेता है जो वांछित revision ID होता है। rel negotiator एक version argument लेता है जो या तो latest-version या working-copy स्ट्रिंग होता है।

भविष्य में, अन्य negotiators विकसित किए जा सकते हैं। उदाहरण के लिए, एक negotiator जो timestamp या workspace आधारित हो।

यह दिखाने के लिए कि किसी विशेष entity revision को कैसे अनुरोध किया जाता है, मान लें कि एक node का "Published" revision और उसके बाद एक "Draft" revision है।

JSON:API का उपयोग करके, "Published" node को इस तरह अनुरोध किया जा सकता है: /jsonapi/node/page/{{uuid}}?resourceVersion=rel:latest-version।

किसी ऐसी entity का प्रीव्यू करने के लिए जो अभी कार्य प्रगति पर है (यानी "Draft" revision), इस तरह अनुरोध किया जा सकता है: /jsonapi/node/page/{{uuid}}?resourceVersion=rel:working-copy।

किसी विशेष revision ID का अनुरोध करने के लिए इस तरह किया जा सकता है: /jsonapi/node/page/{{uuid}}?resourceVersion=id:{{revision_id}}।

अभी तक revisions का संग्रह अनुरोध करना संभव नहीं है। यह अभी भी विकास के अंतर्गत है। देखें: #3009588: एक collection resource प्रदान करें जहाँ version history प्राप्त की जा सके (`version-history`, `predecessor-version` और `successor-version` लिंक रिलेशन)।

लेख स्रोत: Drupal Documentation।