2016-06-09 5 views
6

क्या पैच विधि प्रतिक्रिया निकाय में संसाधन के सभी क्षेत्रों को वापस करनी चाहिए?
या इसे केवल अद्यतन फ़ील्ड लौटा देना चाहिए?
क्या पैच विधि प्रतिक्रिया निकाय में संसाधन के सभी क्षेत्रों को वापस करनी चाहिए?

मैं this

उदाहरण के लिए पढ़ रहा हूँ, अगर यह केवल फ़ील्ड अपडेट रिटर्न, उपयोगकर्ता पता सकता है, जबकि उपयोगकर्ता कुछ फ़ील्ड अपडेट जो खेतों, सर्वर में अपडेट किए गए थे।

**Users resource representations** 
name: string 
age: number 
createdon: date 
modifiedon: date 


PATCH /users/{userId} 
Request body 
{ 
    name: 'changedname', 
} 


Response body Case1 
{ 
    name: 'changedname', 
    age: 20, 
    createdon: 2016-01-01, 
    modifiedon: 2016-06-09 
} 


Response body Case2 
{ 
    name: 'changedname', 
    modifiedon: 2016-06-09 
} 

उत्तर

3

आम तौर पर इसे content negotiation के माध्यम से संभाला जाना चाहिए। दूसरे शब्दों में, क्लाइंट एक विशिष्ट प्रतिनिधित्व के लिए पूछता है यदि उसे एक की आवश्यकता है। अनुरोध इस प्रकार दिखाई देगा:

PATCH /user/123 
Content-Type: application/merge-patch+json 
Accept: application/vnd.company.user+json 
... 

इस मामले में, ग्राहक को व्यक्त करता है कि यह जवाब के रूप में एक पूर्ण user प्रतिनिधित्व चाहता है। या यह कर सकता है:

PATCH /user/123 
Content-Type: application/merge-patch+json 
Accept: application/vnd.company.object-fragment+json 
... 

कुछ वस्तु के सामान्य खंड प्रतिनिधित्व के लिए पूछने के लिए।

यदि आप नहीं चाहते हैं तो आपको दोनों को लागू करने की आवश्यकता नहीं है, इस मामले में आप केवल अपना उपयोग-केस करते हैं और 406 Not Acceptable से media-types पर प्रतिक्रिया देते हैं, तो आप इस पल के लिए समर्थन नहीं करते हैं।

0

मुझे नहीं लगता कि आरईएस टी विनिर्देश (बीटीडब्ल्यू मुझे लगता है कि आपको इसके लिए RFC 6902 पर देखने की आवश्यकता है) इस के आसपास किसी भी मजबूत नियम लागू करता है (आपको क्या लौटना चाहिए)। मैं बल्कि पूरे संसाधन को वापस कर दूंगा ताकि क्लाइंट इसे किसी भी तरह से उपयोग कर सके। सैद्धांतिक रूप से, ग्राहक स्वयं जानता है कि क्या किया गया है (कम से कम अनुरोध क्या था)। सर्वर से पुष्टि प्राप्त करना मामूली नहीं हो सकता है (विशेष रूप से यह देखते हुए कि पैच ज्यादातर संग्रह के लिए उपयोग किया जाता है), या कम से कम सार्थक नहीं है।

+0

आरएफसी 578 9, खंड 2.1: https://tools.ietf.org/html/rfc5789#section-2.1 –

+0

में एक परिभाषा है हालांकि उत्सुकता से यह किसी दस्तावेज़ की बात करता है, लेकिन कुछ भी नहीं। '' मौजूदा पाठ फ़ाइल में सफल PATCH प्रतिक्रिया: HTTP/1.1 204 कोई सामग्री नहीं सामग्री-स्थान: /file.txt ETag: "e0023aa4f" '' –

+0

हालांकि, यह भी कहते हैं: '' नोट अन्य सफलता है कि कोड भी इस्तेमाल किया जा सकता है। '' (204 के अलावा) –

3

पैच के विनिर्देशन को यह अनिवार्य नहीं है।

यदि आप इसे नियंत्रित करना चाहते हैं तो आप प्रेरणा के लिए https://greenbytes.de/tech/webdav/rfc7240.html#return पर देखना चाह सकते हैं।

+0

मुझे नहीं पता था कि हेडर पसंदीदा !! धन्यवाद!! – Nigiri

संबंधित मुद्दे

 संबंधित मुद्दे