208

मैं ग्राहक प्रबंधन प्रणाली के लिए एक RESTful सेवा लिख रहा हूं और मैं आंशिक रूप से रिकॉर्ड अपडेट करने के लिए सर्वोत्तम अभ्यास खोजने की कोशिश कर रहा हूं। उदाहरण के लिए, मैं चाहता हूं कि कॉलर जीईटी अनुरोध के साथ पूरा रिकॉर्ड पढ़ने में सक्षम हो। लेकिन इसे अपडेट करने के लिए केवल रिकॉर्ड पर कुछ संचालन की अनुमति है, जैसे ENABLED से DISABLED में स्थिति बदलना। (मेरे पास इससे अधिक जटिल परिदृश्य हैं)

मैं नहीं चाहता कि कॉलर सुरक्षा कारणों से अपडेट किए गए फ़ील्ड के साथ पूरे रिकॉर्ड को प्रस्तुत करे (यह भी ओवरकिल जैसा लगता है)।

क्या यूआरआई के निर्माण का अनुशंसित तरीका है? जब REST पुस्तकें पढ़ रहे हों तो RPC स्टाइल कॉल फेक लगती हैं।

अगर निम्नलिखित कॉल आईडी 123 के साथ ग्राहक के लिए पूर्ण ग्राहक रिकॉर्ड लौटाता है

GET /customer/123
<customer>
    {lots of attributes}
    <status>ENABLED</status>
    {even more attributes}
</customer>

मुझे स्थिति कैसे अपडेट करनी चाहिए?

POST /customer/123/status
<status>DISABLED</status>

POST /customer/123/changeStatus
DISABLED

...

अपडेट : प्रश्न को बढ़ाने के लिए। REST एपीआई में कोई 'व्यावसायिक तर्क कॉल' कैसे शामिल करता है? क्या ऐसा करने का कोई सहमत तरीका है? सभी विधियां प्रकृति द्वारा CRUD नहीं हैं। कुछ और अधिक जटिल हैं, जैसे ' sendEmailToCustomer (123) ', ' mergeCustomers (123, 456) ', ' countCustomers () '

POST /customer/123?cmd=sendEmail

POST /cmd/sendEmail?customerId=123

GET /customer/count

rest

— magiconair
स्रोत

3

"बिजनेस लॉजिक कॉल्स" के बारे में आपके प्रश्न का उत्तर देने के लिए यहां POSTरॉय फील्डिंग से एक पोस्ट है : roy.gbiv.com/untangled/2009/it-is-okay-to-use-post जहां मूल विचार है: अगर कोई है एक विधि (जैसे कि GETया तो PUT) आदर्श रूप से आपके ऑपरेशन उपयोग के लिए अनुकूल है POST।

— रोजा

यह बहुत ज्यादा है जो मैंने किया है। GET, PUT, DELETE का उपयोग करके ज्ञात संसाधनों को पुनः प्राप्त करने और अद्यतन करने के लिए REST कॉल करें। व्यापार तर्क कॉल के लिए कुछ वर्णनात्मक URL के साथ नए संसाधनों और POST को जोड़ने के लिए POST।

— जादूगरन

जो भी आप तय करते हैं, यदि वह ऑपरेशन GET प्रतिक्रिया का हिस्सा नहीं है, तो आपके पास एक RESTful सेवा नहीं है। मैं यहाँ नहीं देख रहा हूँ

— MStodd

69

आपके पास मूल रूप से दो विकल्प हैं:

उपयोग करें PATCH(लेकिन ध्यान दें कि आपको अपने स्वयं के मीडिया प्रकार को परिभाषित करना होगा जो निर्दिष्ट करता है कि वास्तव में क्या होगा)
POSTएक उप संसाधन का उपयोग करें और 303 लौटें। अन्य को मुख्य संसाधन की ओर इंगित करते हुए स्थान हेडर के साथ देखें। ग्राहक को बताने के लिए 303 का इरादा है: "मैंने आपका POST किया है और इसका प्रभाव यह था कि कुछ अन्य संसाधन को अपडेट किया गया था। उस स्थान के लिए शीर्ष लेख देखें जो कि संसाधन था।" POST / 303 कुछ मुख्य संसाधन की स्थिति का निर्माण करने के लिए संसाधनों में पुनरावृत्ति परिवर्धन के लिए अभिप्रेत है और यह आंशिक अद्यतन के लिए एकदम सही है।

— जान अल्गर्मिसन
स्रोत

ठीक है, POST / 303 मुझे समझ में आता है। PATCH और MERGE मैं मान्य HTTP क्रियाओं की सूची में नहीं पाया जा सकता है ताकि अधिक परीक्षण की आवश्यकता हो। यदि मैं सिस्टम 123 को ग्राहक को ईमेल भेजना चाहता हूं तो मैं एक यूआरआई का निर्माण कैसे करूंगा? एक शुद्ध RPC विधि कॉल की तरह कुछ है जो वस्तु की स्थिति को बिल्कुल भी नहीं बदलता है। ऐसा करने का Restful तरीका क्या है?

— जादूगरन

मुझे ईमेल URI प्रश्न समझ नहीं आ रहा है। क्या आप एक गेटवे लागू करना चाहते हैं जिसे आप ईमेल भेजने के लिए POST कर सकते हैं या आप mailto: customer.123@service.org की तलाश कर रहे हैं?

— Jan Algermissen

15

CRUD के साथ HTTP तरीकों की बराबरी करने वाले कुछ लोगों से अलग न तो REST और न ही HTTP का CRUD से कोई लेना-देना है। REST अभ्यावेदन को स्थानांतरित करके संसाधन की स्थिति में हेरफेर करने के बारे में है। जो कुछ भी आप करना चाहते हैं, वह आपको उपयुक्त शब्दार्थ के साथ एक संसाधन में प्रतिनिधित्व हस्तांतरित करके प्राप्त करना है। 'शुद्ध विधि कॉल' या 'व्यावसायिक तर्क' की शर्तों से सावधान रहें क्योंकि वे बहुत आसानी से 'HTTP ट्रांसपोर्ट के लिए' हैं। यदि आपको एक ईमेल भेजने की आवश्यकता है, एक गेटवे संसाधन के लिए POST, यदि आपको खातों में विलय करने की आवश्यकता है, तो एक नया बनाएं और अन्य दो का POST प्रतिनिधित्व, आदि

— Jan Algermissen

9

यह भी देखें कि Google यह कैसे करता है: googlecode.blogspot.com/2010/03/…

— Marius

4

williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot PATCH [{"op": "test", "path": "/ a / b / c", "value" : "foo"}, {"op": "remove", "path": "/ a / b / c"}, {"op": "add", "path": "/ a / b / c" , "मूल्य": ["फू", "बार"]}, {"op": "प्रतिस्थापित", "पथ": "/ a / b / c", "मूल्य": 42}, {"op": "चाल", "से": "/ a / b / c", "पथ": "/ a / b / d"}, {"op": "copy", "from": "/ a / b /" d "," पथ ":" / a / b / e "}]

— intotecho

48

आपको आंशिक अपडेट के लिए POST का उपयोग करना चाहिए।

ग्राहक के लिए फ़ील्ड्स को अद्यतन करने के लिए 123, POST को / ग्राहक / 123 करें।

यदि आप सिर्फ स्टेटस को अपडेट करना चाहते हैं, तो आप PUT / to / customer / 123 / स्टेटस भी कर सकते हैं।

आमतौर पर, GET अनुरोधों का कोई दुष्प्रभाव नहीं होना चाहिए, और PUT पूरे संसाधन को लिखने / बदलने के लिए है।

यह सीधे HTTP से आता है, जैसा कि यहाँ देखा गया है: http://en.wikipedia.org/wiki/HTTP_PUT#Request_methods

— wsorenson
स्रोत

1

@ जॉन सौन्डर्स POST को आवश्यक रूप से एक नया संसाधन नहीं बनाना है जो URI से सुलभ हो: tools.ietf.org/html/rfc2616#section-9.5

— wsorenson

10

@ युसरेन्सेन: मुझे पता है कि इसके परिणामस्वरूप एक नए URL की आवश्यकता नहीं है, लेकिन फिर भी एक POST ने सोचा /customer/123कि जो चीज़ तार्किक रूप से ग्राहक 123 के अधीन है, उसे बनाना चाहिए। शायद एक आदेश? करने के लिए रखा /customer/123/statusहै, बेहतर समझ बनाने के लिए लगता है पोस्ट संभालने के लिए /customersपरोक्ष एक बनाया status(यह मानते हुए कि कानूनी REST)।

— जॉन सॉन्डर्स

1

@ जॉन सौन्डर्स: व्यावहारिक रूप से, अगर हम किसी दिए गए URI में स्थित संसाधन पर एक फ़ील्ड को अपडेट करना चाहते हैं, तो POST PUT की तुलना में अधिक समझ में आता है, और एक UPDATE का अभाव है, मेरा मानना है कि इसका उपयोग अक्सर REST सेवाओं में किया जाता है। POST / to ग्राहक एक नया ग्राहक बना सकते हैं, और PUT / / ग्राहक / 123 / स्थिति विनिर्देशन के शब्द के साथ बेहतर संरेखित कर सकते हैं, लेकिन सर्वोत्तम प्रथाओं के लिए, मुझे नहीं लगता कि POST / करने के लिए कोई कारण नहीं है ग्राहक / 123 एक क्षेत्र को अद्यतन करने के लिए - यह संक्षिप्त है, समझ में आता है, और विनिर्देश में किसी भी चीज़ के खिलाफ कड़ाई से नहीं जाता है।

— wsorenson

8

क्या POST अनुरोधों को निष्प्रभावी नहीं होना चाहिए? निश्चित रूप से एक प्रविष्टि को अद्यतन करना उदासीन है और इस प्रकार इसके बजाय एक PUT होना चाहिए?

— मार्टिन एंडरसन 8

1

@MartinAndersson POST-requests नॉन- इम्पोटेंट होने की जरूरत नहीं है । और जैसा कि उल्लेख किया गया है, PUTपूरे संसाधन को बदलना होगा।

— हाले क्नास्ट २ H

10

आपको आंशिक अपडेट के लिए PATCH का उपयोग करना चाहिए - या तो json-पैच दस्तावेज़ों का उपयोग करना (देखें http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-08 या http://www.mnot.net/ ब्लॉग / 2012/09/05 / पैच ) या XML पैच फ्रेमवर्क (देखें http://tools.ietf.org/html/rfc5261 )। मेरी राय में, हालांकि, json-पैच आपके व्यवसाय डेटा के लिए सबसे उपयुक्त है।

JSON / XML पैच दस्तावेज़ों के साथ PATCH ने आंशिक अपडेट के लिए फॉरवर्ड सिमेंटिक्स को बहुत स्ट्रेट किया है। यदि आप मूल दस्तावेज़ की संशोधित प्रतियों के साथ POST का उपयोग करना शुरू करते हैं, तो आंशिक अपडेट के लिए आप जल्द ही उन समस्याओं में भाग लेते हैं जहाँ आप लापता मान (या बल्कि, शून्य मान) चाहते हैं कि "इस संपत्ति को अनदेखा करें" या "इस संपत्ति को सेट करें" रिक्त मान "- और यह हैक किए गए समाधानों के एक खरगोश छेद का नेतृत्व करता है जो अंत में आपके अपने प्रकार के पैच प्रारूप में परिणाम देगा।

आप अधिक गहराई से उत्तर यहां पा सकते हैं: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html ।

— जोर्न वाइल्ड
स्रोत

कृपया ध्यान दें कि इस बीच json- पैच और xml- पैच के लिए RFC को अंतिम रूप दिया गया है।

— बॉटनकियाक

8

मैं एक ऐसी ही समस्या में चल रहा हूं। जब आप केवल एक फ़ील्ड को अपडेट करना चाहते हैं, तो उप-संसाधन पर PUT काम करता है। हालांकि, कभी-कभी आप चीजों का एक गुच्छा अपडेट करना चाहते हैं: कुछ प्रविष्टियों को बदलने के लिए विकल्प के साथ संसाधन का प्रतिनिधित्व करने वाले एक वेब फॉर्म के बारे में सोचें। उपयोगकर्ता का फॉर्म जमा करने का परिणाम कई PUTs में नहीं होना चाहिए।

यहाँ दो समाधान हैं जो मैं सोच सकता हूँ:

पूरे संसाधन के साथ एक PUT करें। सर्वर-साइड पर, शब्दार्थ को परिभाषित करें जो कि पूरे संसाधन के साथ एक PUT उन सभी मानों को अनदेखा करता है जो परिवर्तित नहीं हुए हैं।
आंशिक संसाधन के साथ PUT करें। सर्वर-साइड पर, इस शब्दार्थ को एक मर्ज के रूप में परिभाषित करें।

2 सिर्फ 1 की बैंडविड्थ-अनुकूलन है। कभी-कभी 1 एकमात्र विकल्प होता है यदि संसाधन परिभाषित करता है कि कुछ फ़ील्ड आवश्यक फ़ील्ड हैं (लगता है कि प्रोटो बफ़र)।

इन दोनों दृष्टिकोणों के साथ समस्या यह है कि किसी क्षेत्र को कैसे साफ़ किया जाए। आपको एक विशेष शून्य मान को परिभाषित करना होगा (विशेष रूप से प्रोटो बफ़र्स के लिए चूंकि शून्य मान प्रोटो बफ़र्स के लिए परिभाषित नहीं हैं) जो क्षेत्र को साफ़ करने का कारण होगा।

टिप्पणियाँ?

— user360657
स्रोत

2

यह एक अलग प्रश्न के रूप में पोस्ट किया गया तो अधिक उपयोगी होगा।

— इंटेकचो डिक्

6

स्थिति को संशोधित करने के लिए मुझे लगता है कि एक RESTful दृष्टिकोण एक तार्किक उप-संसाधन का उपयोग करना है जो संसाधनों की स्थिति का वर्णन करता है। यह IMO बहुत उपयोगी और साफ है जब आपके पास स्थितियों का एक छोटा सेट होता है। यह आपके API को आपके ग्राहक संसाधन के लिए मौजूदा संचालन के बिना अधिक स्पष्ट बनाता है।

उदाहरण:

POST /customer/active  <-- Providing entity in the body a new customer
{
  ...  // attributes here except status
}

POST सेवा को आईडी के साथ नए बनाए गए ग्राहक को वापस करना चाहिए:

{
    id:123,
    ...  // the other fields here
}

निर्मित संसाधन के लिए GET संसाधन स्थान का उपयोग करेगा:

GET /customer/123/active

एक GET / ग्राहक / 123 / निष्क्रिय 404 वापस आना चाहिए

PUT ऑपरेशन के लिए, Json निकाय प्रदान किए बिना यह केवल स्थिति को अद्यतन करेगा

PUT /customer/123/inactive  <-- Deactivating an existing customer

एक इकाई प्रदान करने से आप ग्राहक की सामग्री को अपडेट कर सकते हैं और उसी समय स्थिति को अपडेट कर सकते हैं।

PUT /customer/123/inactive
{
    ...  // entity fields here except id and status
}

आप अपने ग्राहक संसाधन के लिए एक वैचारिक उप-संसाधन बना रहे हैं। यह रॉय फील्डिंग की एक संसाधन की परिभाषा के साथ भी सुसंगत है: "... एक संसाधन संस्थाओं के एक वैचारिक मानचित्रण है, न कि वह इकाई जो किसी विशेष बिंदु पर मैपिंग से मेल खाती है ..." इस मामले में वैचारिक मानचित्रण सक्रिय ग्राहक से स्थिति = सक्रिय के साथ ग्राहक है।

पढ़ें ऑपरेशन:

GET /customer/123/active 
GET /customer/123/inactive

यदि आप उन कॉल को एक के बाद एक सही करते हैं तो उनमें से किसी एक को स्थिति 404 को वापस करना होगा, सफल आउटपुट में वह स्थिति शामिल नहीं हो सकती जितनी कि निहित है। बेशक आप अभी भी GET / ग्राहक / 123 का उपयोग कर सकते हैं? स्थिति = ACTIVE | सीधे ग्राहक संसाधन की क्वेरी करने के लिए।

DELETE ऑपरेशन दिलचस्प है क्योंकि शब्दार्थ भ्रमित हो सकता है। लेकिन आपके पास इस वैचारिक संसाधन के लिए उस ऑपरेशन को प्रकाशित नहीं करने का विकल्प है, या अपने व्यावसायिक तर्क के अनुसार इसका उपयोग करें।

DELETE /customer/123/active

वह व्यक्ति आपके ग्राहक को DELETED / DISABLED स्थिति या विपरीत स्थिति (ACTIVE / INACTIVE) तक ले जा सकता है।

— raspacorp
स्रोत

आपको उप-संसाधन कैसे प्राप्त होंगे?

— MStodd

मैंने उत्तर को और अधिक स्पष्ट करने की कोशिश करते हुए

— मना कर

5

अपने संवर्धित प्रश्न में जोड़ने के लिए चीजें। मुझे लगता है कि आप अक्सर अधिक जटिल व्यावसायिक कार्यों को पूरी तरह से डिजाइन कर सकते हैं। लेकिन आपको संसाधनों और क्रियाओं में अधिक सोचने और सोचने की विधि / प्रक्रिया शैली को छोड़ना होगा।

मेल भेजना


POST /customers/123/mails

payload:
{from: x@x.com, subject: "foo", to: y@y.com}

इस संसाधन + POST के लागू होने के बाद मेल बाहर भेजा जाएगा। यदि आवश्यक हो तो आप कुछ / ग्राहक / 123 / आउटबॉक्स की पेशकश कर सकते हैं और फिर / ग्राहक / मेल / {mailId} के लिए संसाधन लिंक प्रदान कर सकते हैं।

ग्राहक की गिनती

आप इसे एक खोज संसाधन की तरह संभाल सकते हैं (पेजिंग और संख्या-मिली जानकारी के साथ खोज मेटाडेटा, जो आपको ग्राहकों की गिनती देता है)।


GET /customers

response payload:
{numFound: 1234, paging: {self:..., next:..., previous:...} customer: { ...} ....}

— मैनुअल अलदाना
स्रोत

मुझे POST उप-संसाधन में खेतों के तार्किक समूहन का तरीका पसंद है।

— गर्टस

3

अपूर्ण / आंशिक संसाधन को अपडेट करने के लिए PUT का उपयोग करें।

आप jObject को पैरामीटर के रूप में स्वीकार कर सकते हैं और संसाधन को अद्यतन करने के लिए इसके मान को पार्स कर सकते हैं।

नीचे एक फ़ंक्शन है जिसे आप संदर्भ के रूप में उपयोग कर सकते हैं:

public IHttpActionResult Put(int id, JObject partialObject)
{
    Dictionary<string, string> dictionaryObject = new Dictionary<string, string>();

    foreach (JProperty property in json.Properties())
    {
        dictionaryObject.Add(property.Name.ToString(), property.Value.ToString());
    }

    int id = Convert.ToInt32(dictionaryObject["id"]);
    DateTime startTime = Convert.ToDateTime(orderInsert["AppointmentDateTime"]);            
    Boolean isGroup = Convert.ToBoolean(dictionaryObject["IsGroup"]);

    //Call function to update resource
    update(id, startTime, isGroup);

    return Ok(appointmentModelList);
}

— पुनीत पाठक
स्रोत

2

आपके अपडेट के बारे में।

सीआरयूडी की अवधारणा मुझे विश्वास है कि एपीआई डिजाइन के बारे में कुछ भ्रम है। CRUD डेटा पर प्रदर्शन करने के लिए बुनियादी संचालन के लिए एक सामान्य निम्न स्तर की अवधारणा है, और HTTP क्रियाएं केवल अनुरोध विधियां हैं ( 21 साल पहले बनाई गई थीं ) जो CRUD ऑपरेशन के लिए मैप हो सकती हैं या नहीं भी। वास्तव में, HTTP 1.0 / 1.1 विनिर्देशन में CRUD के संक्षिप्त रूप की उपस्थिति का पता लगाने का प्रयास करें।

एक बहुत अच्छी तरह से समझाया गया गाइड जो एक व्यावहारिक सम्मेलन को लागू करता है, Google क्लाउड प्लेटफ़ॉर्म एपीआई प्रलेखन में पाया जा सकता है । यह एक संसाधन आधारित एपीआई के निर्माण के पीछे की अवधारणाओं का वर्णन करता है, एक जो परिचालन पर संसाधनों की एक बड़ी मात्रा पर जोर देता है, और उन उपयोग मामलों को भी शामिल करता है जिन्हें आप वर्णन कर रहे हैं। हालांकि उनके उत्पाद के लिए एक सम्मेलन डिजाइन है, मुझे लगता है कि यह बहुत मायने रखता है।

यहाँ आधार अवधारणा (और जो बहुत भ्रम पैदा करती है) "विधियों" और HTTP क्रियाओं के बीच मानचित्रण है। एक बात यह निर्धारित करना है कि आपके एपीआई किस प्रकार के "ऑपरेशन" (तरीके) करेंगे जो कि किस प्रकार के संसाधनों पर (उदाहरण के लिए, ग्राहकों की एक सूची प्राप्त करें, या एक ईमेल भेजें), और दूसरा HTTP क्रियाएं हैं। दोनों की परिभाषा होनी चाहिए, उन तरीकों और क्रियाओं की जिन्हें आप उपयोग करने की योजना बनाते हैं और ए उनके बीच मैपिंग है ।

यह भी है कि कहते हैं, एक ऑपरेशन एक मानक विधि के साथ वास्तव में नक्शा नहीं है जब ( List, Get, Create, Update, Deleteइस मामले में), एक का उपयोग कर सकते हैं "कस्टम तरीकों" की तरह BatchGetहै, जो कई ऑब्जेक्ट id इनपुट के आधार पर कई वस्तुओं प्राप्त करता है, या SendEmail।

— atoledo
स्रोत

2

RFC 7396 : JSON मर्ज पैच (प्रश्न पोस्ट किए जाने के चार साल बाद प्रकाशित) प्रारूप और प्रसंस्करण नियमों के संदर्भ में एक PATCH के लिए सर्वोत्तम प्रथाओं का वर्णन करता है।

संक्षेप में, आप एक HTTP PATCH को अनुप्रयोग / मर्ज-पैच + json के साथ लक्ष्य संसाधन में जमा करते हैं MIME मीडिया प्रकार के करते हैं और केवल उन भागों का प्रतिनिधित्व करने वाला एक निकाय जो आप बदलना / जोड़ना / हटाना चाहते हैं और फिर नीचे दिए गए प्रसंस्करण नियमों का पालन करें।

नियम :

यदि प्रदान किए गए मर्ज पैच में सदस्य होते हैं जो लक्ष्य के भीतर दिखाई नहीं देते हैं, तो उन सदस्यों को जोड़ा जाता है।

यदि लक्ष्य में सदस्य नहीं है, तो मान बदल दिया जाता है।

लक्ष्य में मौजूदा मूल्यों को हटाने का संकेत देने के लिए मर्ज पैच में अशक्त मानों को विशेष अर्थ दिया जाता है।

उदाहरण के परीक्षण मामले जो ऊपर दिए गए नियमों का वर्णन करते हैं (जैसा कि उस RFC के परिशिष्ट में देखा गया है ):

 ORIGINAL         PATCH           RESULT
--------------------------------------------
{"a":"b"}       {"a":"c"}       {"a":"c"}

{"a":"b"}       {"b":"c"}       {"a":"b",
                                 "b":"c"}
{"a":"b"}       {"a":null}      {}

{"a":"b",       {"a":null}      {"b":"c"}
"b":"c"}

{"a":["b"]}     {"a":"c"}       {"a":"c"}

{"a":"c"}       {"a":["b"]}     {"a":["b"]}

{"a": {         {"a": {         {"a": {
  "b": "c"}       "b": "d",       "b": "d"
}                 "c": null}      }
                }               }

{"a": [         {"a": [1]}      {"a": [1]}
  {"b":"c"}
 ]
}

["a","b"]       ["c","d"]       ["c","d"]

{"a":"b"}       ["c"]           ["c"]

{"a":"foo"}     null            null

{"a":"foo"}     "bar"           "bar"

{"e":null}      {"a":1}         {"e":null,
                                 "a":1}

[1,2]           {"a":"b",       {"a":"b"}
                 "c":null}

{}              {"a":            {"a":
                 {"bb":           {"bb":
                  {"ccc":          {}}}
                   null}}}

— Voicu
स्रोत

1

की जाँच करें http://www.odata.org/

यह MERGE विधि को परिभाषित करता है, इसलिए आपके मामले में यह कुछ इस तरह होगा:

MERGE /customer/123

<customer>
   <status>DISABLED</status>
</customer>

केवल statusसंपत्ति को अद्यतन किया जाता है और अन्य मान संरक्षित किए जाते हैं।

— मैक्स टोरो
स्रोत

है MERGEएक मान्य HTTP क्रिया?

— जॉन सॉन्डर्स

3

PATCH को देखें - जो जल्द ही मानक HTTP हो सकता है और वही काम करता है।

— Jan Algermissen

@ जॉन सौन्डर्स हां, यह एक विस्तार विधि है।

— मैक्स टोरो

FYI MERGE को OData v4 से हटा दिया गया है। Docs.oasis-open.org/odata/new-in-odata/v4.0/cn01/…MERGE was used to do PATCH before PATCH existed. Now that we have PATCH, we no longer need MERGE.

— tanguy_k

0

इससे कोई फर्क नहीं पड़ता। REST के संदर्भ में, आप एक GET नहीं कर सकते, क्योंकि यह देखने योग्य नहीं है, लेकिन इससे कोई फर्क नहीं पड़ता कि आप POST या PATCH या PUT का उपयोग करते हैं या जो भी हो, और इससे कोई फर्क नहीं पड़ता कि URL कैसा दिखता है। यदि आप REST कर रहे हैं, तो क्या मायने रखता है कि जब आप सर्वर से अपने संसाधन का प्रतिनिधित्व प्राप्त करते हैं, तो वह प्रतिनिधित्व क्लाइंट स्टेट ट्रांज़िशन विकल्प देने में सक्षम होता है।

यदि आपकी GET प्रतिक्रिया में स्टेट ट्रांज़ेक्शन था, तो क्लाइंट को बस यह जानना होगा कि उन्हें कैसे पढ़ना है, और ज़रूरत पड़ने पर सर्वर उन्हें बदल सकता है। यहां POST का उपयोग करके एक अपडेट किया जाता है, लेकिन अगर इसे PATCH में बदल दिया गया, या यदि URL बदल गया, तो क्लाइंट को अभी भी पता है कि अपडेट कैसे करना है:

{
  "customer" :
  {
  },
  "operations":
  [
    "update" : 
    {
      "method": "POST",
      "href": "https://server/customer/123/"
    }]
}

आप क्लाइंट को वापस देने के लिए आवश्यक / वैकल्पिक मापदंडों को सूचीबद्ध करने के लिए आप तक जा सकते हैं। यह एप्लिकेशन पर निर्भर करता है।

जहाँ तक व्यवसाय संचालन, ग्राहक संसाधन से जुड़ा एक अलग संसाधन हो सकता है। यदि आप ग्राहक को एक ईमेल भेजना चाहते हैं, तो शायद यह सेवा स्वयं का संसाधन है जिसे आप पोस्ट कर सकते हैं, इसलिए आप ग्राहक संसाधन में निम्नलिखित ऑपरेशन को शामिल कर सकते हैं:

"email":
{
  "method": "POST",
  "href": "http://server/emailservice/send?customer=1234"
}

कुछ अच्छे वीडियो, और प्रस्तुतकर्ता की REST वास्तुकला के उदाहरण ये हैं। स्टॉर्मपैथ केवल GET / POST / DELETE का उपयोग करता है, जो कि ठीक है क्योंकि REST का आपके द्वारा उपयोग किए जाने वाले ऑपरेशनों के साथ कुछ भी नहीं है या URL कैसे दिखना चाहिए (GET को छोड़कर अन्य को देखने योग्य होना चाहिए):

https://www.youtube.com/watch?v=pspy1H6A3FM ,
https://www.youtube.com/watch?v=5WXYw4J4QOU ,
http://docs.stormpath.com/rest/quickstart/

— MStodd
स्रोत

एक RESTful सेवा में आंशिक अपडेट के लिए सर्वश्रेष्ठ अभ्यास

मेल भेजना

ग्राहक की गिनती