web services - आरईएसटी को समझना: क्रियाएं, त्रुटि कोड, और प्रमाणीकरण




web-services rest (7)

रीस्ट मूल बातें

आरईएसटी की एक समान इंटरफेस बाधा है, जिसमें कहा गया है कि आरईएसटी क्लाइंट को वास्तविक आरईएसटी सेवा के आवेदन विशिष्ट विवरणों के बजाय मानकों पर भरोसा करना चाहिए, इसलिए आरईएसटी क्लाइंट मामूली बदलावों से नहीं टूट जाएगा, और यह संभवतः पुन: प्रयोज्य होगा।

तो आरईएसटी क्लाइंट और आरईएसटी सेवा के बीच एक अनुबंध है। यदि आप अंतर्निहित प्रोटोकॉल के रूप में HTTP का उपयोग करते हैं, तो निम्न मानदंड अनुबंध का हिस्सा हैं:

  • HTTP 1.1
    • विधि परिभाषाएं
    • स्थिति कोड परिभाषाएं
    • कैश नियंत्रण हेडर
    • स्वीकार करें और सामग्री-प्रकार शीर्षलेख
    • ऑथ हेडर
  • IRI (यूटीएफ 8 URI )
  • शरीर (एक उठाओ)
    • पंजीकृत आवेदन विशिष्ट एमआईएम प्रकार, उदाहरण के लिए maze+xml
    • विक्रेता विशिष्ट एमआईएम प्रकार, उदाहरण के लिए vnd.github+json
    • जेनेरिक एमआईएम प्रकार के साथ
      • आवेदन विशिष्ट आरडीएफ vocab, उदाहरण के लिए ld+json और hydra , schema.org
      • एप्लिकेशन विशिष्ट प्रोफ़ाइल, उदाहरण के लिए hal+json और प्रोफाइल लिंक परम (मुझे लगता है)
  • हाइपरलिंक
    • उन्हें क्या होना चाहिए (एक चुनें)
      • लिंक हेडर में भेजना
      • एक हाइपरमीडिया प्रतिक्रिया में भेजना, जैसे एचटीएमएल, परमाणु + एक्सएमएल, हॉल + जेसन, एलडी + जेसन और हाइड्रा, आदि ...
    • अर्थ विज्ञान
      • आईएएनए लिंक संबंधों और शायद कस्टम लिंक संबंधों का उपयोग करें
      • एक आवेदन विशिष्ट आरडीएफ vocab का उपयोग करें

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

आपको सवालों के जवाब देने के लिए

  1. हाँ, यह हो सकता है।

    बस उल्लेख करने के लिए, ग्राहकों को आईआरआई संरचना की परवाह नहीं है, वे अर्थशास्त्र के बारे में परवाह करते हैं, क्योंकि वे लिंक संबंधों या लिंक किए गए डेटा (आरडीएफ) विशेषताओं वाले लिंक का पालन करते हैं।

    आईआरआई के बारे में एकमात्र चीज महत्वपूर्ण है, कि एक आईआरआई को केवल एक ही संसाधन की पहचान करनी चाहिए। इसे एक ही संसाधन की अनुमति है, जैसे उपयोगकर्ता, कई अलग-अलग आईआरआई हैं।

    यह बहुत आसान है कि हम अच्छे आईआरआई जैसे /users/123/password उपयोग क्यों करते /users/123/password ; जब आप आईआरआई को इसे पढ़कर समझते हैं तो सर्वर पर रूटिंग तर्क लिखना बहुत आसान होता है।

  2. आपके पास पुट, पैच, विकल्प और इससे भी अधिक की तरह अधिक क्रियाएं हैं, लेकिन आपको उनमें से अधिक की आवश्यकता नहीं है ... नए क्रियाओं को जोड़ने के बजाय आपको नए संसाधनों को जोड़ने का तरीका सीखना होगा।

    activate_login -> PUT /login/active true deactivate_login -> PUT /login/active false change_password -> PUT /user/xy/password "newpass" add_credit -> POST /credit/raise {details: {}}

    (स्टेटलेस बाधा के कारण, लॉगिन आरईएसटी परिप्रेक्ष्य से समझ में नहीं आता है।)

  3. आपके उपयोगकर्ताओं को इस बात की परवाह नहीं है कि समस्या क्यों मौजूद है। वे केवल तभी जानना चाहते हैं जब सफलता या त्रुटि हो, और शायद एक त्रुटि संदेश जिसे वे समझ सकें, उदाहरण के लिए: "क्षमा करें, लेकिन हम आपकी पोस्ट को सहेजने में सक्षम नहीं थे।", आदि ...

    HTTP स्टेटस हेडर आपके मानक शीर्षलेख हैं। मुझे लगता है कि शरीर में सबकुछ होना चाहिए। उदाहरण के लिए विस्तृत बहुभाषी त्रुटि संदेशों का वर्णन करने के लिए एक एकल शीर्षलेख पर्याप्त नहीं है।

  4. स्टेटलेस बाधा (कैश और स्तरित सिस्टम बाधाओं के साथ) यह सुनिश्चित करता है कि सेवा अच्छी तरह से स्केल करे। आप निश्चित रूप से सर्वर पर लाखों सत्रों को बनाए रखने के लिए नहीं चाहते हैं, जब आप ग्राहकों पर ऐसा कर सकते हैं ...

    यदि उपयोगकर्ता मुख्य क्लाइंट का उपयोग कर उस तक पहुंच प्रदान करता है तो तृतीय पक्ष क्लाइंट को एक्सेस टोकन मिलता है। उसके बाद तीसरे पक्ष के ग्राहक प्रत्येक अनुरोध के साथ पहुंच टोकन भेजता है। अधिक जटिल समाधान हैं, उदाहरण के लिए आप प्रत्येक अनुरोध पर हस्ताक्षर कर सकते हैं, आदि। अधिक जानकारी के लिए ओएथ मैनुअल की जांच करें।

संबंधित साहित्य

मैं अपने PHP- आधारित वेब अनुप्रयोगों, डेटाबेस और सीएमएस में डिफ़ॉल्ट कार्यों के आसपास एपीआई लपेटने का एक तरीका ढूंढ रहा हूं।

मैंने चारों ओर देखा है और कई "कंकाल" ढांचे को पाया है। मेरे प्रश्न में दिए गए उत्तरों के अलावा, Tonic , मुझे एक आरईएसटी फ्रेमवर्क पसंद है क्योंकि यह बहुत हल्का है।

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

1. क्या मैं इसे सही समझ रहा हूँ?

मान लें कि मेरे पास संसाधन "उपयोगकर्ता" है। मैं इस तरह के कई यूआरआई स्थापित कर सकता था:

/api/users     when called with GET, lists users
/api/users     when called with POST, creates user record
/api/users/1   when called with GET, shows user record
               when called with PUT, updates user record
               when called with DELETE, deletes user record

क्या यह अब तक एक विश्वसनीय वास्तुकला का सही प्रतिनिधित्व है?

2. मुझे और क्रियाओं की आवश्यकता है

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

कुछ जो उपयोगकर्ता के उदाहरण में दिमाग में आते हैं वे हैं:

activate_login
deactivate_login
change_password
add_credit

मैं एक विश्वसनीय यूआरएल आर्किटेक्चर में ऐसे कार्यों को कैसे व्यक्त करूं?

मेरा वृत्ति एक यूआरएल जैसे जीईटी कॉल करना होगा

/api/users/1/activate_login 

और एक स्थिति कोड वापस उम्मीद है।

हालांकि, HTTP क्रियाओं का उपयोग करने के विचार से विचलित हो जाता है। तुम क्या सोचते हो?

3. त्रुटि संदेश और कोड कैसे वापस करें

आरईएसटी की सुंदरता का एक बड़ा हिस्सा मानक HTTP विधियों के उपयोग से उत्पन्न होता है। एक त्रुटि पर, मैं एक 3x, 4xx या 5xx त्रुटि स्थिति कोड के साथ एक शीर्षलेख उत्सर्जित करता हूं। विस्तृत त्रुटि विवरण के लिए, मैं शरीर का उपयोग कर सकता हूं (दाएं?)। अब तक सब ठीक है। लेकिन एक स्वामित्व त्रुटि कोड संचारित करने का तरीका क्या होगा जो गलत होने का वर्णन करने में अधिक विस्तृत है (उदाहरण के लिए "डेटाबेस से कनेक्ट करने में विफल", या "डेटाबेस लॉगिन गलत")? अगर मैं इसे संदेश के साथ शरीर में डालता हूं, तो मुझे इसे बाद में पार्स करना होगा। क्या इस तरह की चीज़ के लिए एक मानक शीर्षलेख है?

4. प्रमाणीकरण कैसे करें

  • आरईएसटी सिद्धांतों के बाद एपीआई कुंजी आधारित प्रमाणीकरण कैसा दिखता है?
  • आरईएसटी क्लाइंट को प्रमाणित करते समय सत्रों का उपयोग करने के खिलाफ मजबूत अंक हैं, इसके अलावा यह आरईएसटी सिद्धांत का एक स्पष्ट उल्लंघन है? :) (यहां केवल आधे मजाक कर रहे हैं, सत्र आधारित प्रमाणीकरण मेरे मौजूदा बुनियादी ढांचे के साथ अच्छी तरह से खेलेंगे।)

  1. पोस्ट का उपयोग करें जब आप नहीं जानते कि नया संसाधन यूआरआई कैसा दिखता है (आप नया उपयोगकर्ता बनाते हैं, एप्लिकेशन नए उपयोगकर्ता को आईडी निर्दिष्ट करेगा), संसाधनों को अद्यतन करने या बनाने के लिए PUT जिसे आप जानते हैं कि उन्हें कैसे प्रदर्शित किया जा रहा है (उदाहरण : PUT /myfiles/thisismynewfile.txt)
  2. संदेश निकाय में त्रुटि विवरण वापस करें
  3. आप HTTP प्रमाणीकरण का उपयोग कर सकते हैं (यदि यह पर्याप्त है) वेब सेवाएं stateles होना चाहिए

आपके द्वारा बताए गए उदाहरणों के लिए मैं निम्नलिखित का उपयोग करूंगा:

activate_login

POST /users/1/activation

deactivate_login

DELETE /users/1/activation

पासवर्ड बदलें

PUT /passwords (यह मानता है कि उपयोगकर्ता प्रमाणीकृत है)

क्रेडिट जोड़ने

POST /credits (यह मानता है कि उपयोगकर्ता प्रमाणित है)

त्रुटियों के लिए आप उस प्रारूप में शरीर में त्रुटि वापस कर देंगे जिसमें आपको अनुरोध मिला है, इसलिए यदि आपको प्राप्त होता है:

DELETE /users/1.xml

आप एक्सएमएल में प्रतिक्रिया वापस भेज देंगे, यह JSON आदि के लिए भी सच होगा ...

प्रमाणीकरण के लिए आपको http प्रमाणीकरण का उपयोग करना चाहिए।


मैं सुझाव दूंगा (पहले पास के रूप में) कि PUT केवल मौजूदा इकाइयों को अद्यतन करने के लिए उपयोग किया जाना चाहिए। POST को नए बनाने के लिए इस्तेमाल किया जाना चाहिए। अर्थात

/api/users     when called with PUT, creates user record

मुझे सही नहीं लगता है। आपका पहला पहला खंड (पुनः क्रिया उपयोग) तार्किक लग रहा है, हालांकि।


सीधे शब्दों में कहें, आप इसे पूरी तरह पिछड़ा कर रहे हैं।

आपको इसका उपयोग नहीं करना चाहिए कि आप किन URL का उपयोग कर रहे हैं। एक बार जब आप यह तय कर लेंगे कि आपके सिस्टम के लिए कौन से संसाधन आवश्यक हैं और आप उन संसाधनों का प्रतिनिधित्व कैसे करेंगे, और संसाधनों और एप्लिकेशन स्थिति के बीच बातचीत कैसे करेंगे, तो URL प्रभावी रूप से "नि: शुल्क" आ जाएंगे।

रॉय फील्डिंग को उद्धृत करने के लिए

एक आरईएसटी एपीआई को संसाधनों का प्रतिनिधित्व करने और आवेदन राज्य चलाने के लिए उपयोग किए जाने वाले मीडिया प्रकार (या) को मौजूदा मानक मीडिया प्रकारों के लिए विस्तारित संबंध नाम और / या हाइपरटेक्स्ट-सक्षम मार्क-अप को परिभाषित करने में लगभग सभी वर्णनात्मक प्रयासों को खर्च करना चाहिए। मीडिया के प्रकार के लिए प्रसंस्करण नियमों के दायरे में (और, ज्यादातर मामलों में, पहले से ही मौजूदा मीडिया प्रकारों द्वारा परिभाषित) के दायरे में यूआरआई के ब्याज पर किस तरीके का उपयोग किया जाना चाहिए, इसका वर्णन करने के लिए खर्च किए गए किसी भी प्रयास का वर्णन किया गया है। [यहां विफलता का तात्पर्य है कि ऑफ-ऑफ-बैंड जानकारी हाइपरटेक्स्ट की बजाय बातचीत चला रही है।]

लोग हमेशा यूआरआई के साथ शुरू करते हैं और सोचते हैं कि यह समाधान है, और फिर वे आरईएसटी आर्किटेक्चर में एक महत्वपूर्ण अवधारणा को याद करते हैं, विशेष रूप से, ऊपर उद्धृत के रूप में, "यहां विफलता का तात्पर्य है कि ऑफ-ऑफ-बैंड जानकारी हाइपरटेक्स्ट की बजाय बातचीत चला रही है। "

ईमानदार होने के लिए, कई यूआरआई और कुछ जीईटी और पुट्स और पोस्ट्स का एक गुच्छा देखते हैं और लगता है कि आरईएसटी आसान है। आरईएसटी आसान नहीं है। HTTP पर आरपीसी आसान है, HTTP पेलोड के माध्यम से पीछे और पीछे डेटा के चलते ब्लॉब्स आसान है। आरईएसटी, हालांकि, उससे परे चला जाता है। आरईएसटी प्रोटोकॉल अज्ञेयवादी है। HTTP आरईएसटी सिस्टम के लिए बहुत लोकप्रिय और उपयुक्त है।

आरईएसटी मीडिया प्रकारों, उनकी परिभाषाओं, और कैसे हाइपरटेक्स्ट (लिंक, प्रभावी ढंग से) के माध्यम से उन संसाधनों के लिए उपलब्ध कार्यों को चलाता है।

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

दोनों दृष्टिकोणों में उनकी जगह है, मुझे लगता है कि एक्सएचटीएमएल उन परिदृश्यों में बहुत अच्छी तरह से काम कर रहा है जो मानव संचालित और मशीन संचालित वेब दोनों को ओवरलैप करते हैं, जबकि पूर्व, अधिक विशिष्ट डेटा प्रकार मैं मशीन इंटरैक्शन के लिए मशीन को बेहतर ढंग से सुविधाजनक महसूस करता हूं। मुझे लगता है कि कमोडिटी प्रारूपों का उत्थान सामग्री बातचीत को संभावित रूप से कठिन बना सकता है। "एप्लिकेशन / एक्सएमएल + आपका संसाधन" मीडिया प्रकार के रूप में "एप्लिकेशन / एक्सएचटीएमएल + एक्सएमएल" की तुलना में अधिक विशिष्ट है, क्योंकि बाद वाले कई पेलोड पर लागू हो सकते हैं जो कि मशीन क्लाइंट वास्तव में रुचि रखते हैं या नहीं भी हो सकता है, न ही यह आत्मनिरीक्षण के बिना निर्धारित करें।

हालांकि, एक्सएचटीएमएल मानव वेब में बहुत अच्छी तरह से काम करता है (स्पष्ट रूप से) जहां वेब ब्राउज़र और प्रतिपादन बहुत महत्वपूर्ण है।

आप आवेदन आपको उन निर्णयों में मार्गदर्शन करेंगे।

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

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

उदाहरण के लिए, आपके पास हो सकता है:

<link href="http://example.com/users" rel="users" type="application/xml+usercollection"/>
<link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/>

आपका दस्तावेज़ "उपयोगकर्ता" नामक रिले फ़ील्ड और "एप्लिकेशन / एक्सएमएल + यूज़र" के मीडिया प्रकार के बारे में बात करेगा।

ये लिंक अनावश्यक प्रतीत हो सकते हैं, वे सभी एक ही यूआरआई से बात कर रहे हैं, बहुत ज्यादा। लेकिन वे नहीं हैं।

ऐसा इसलिए है क्योंकि "उपयोगकर्ता" संबंध के लिए, यह लिंक उपयोगकर्ताओं के संग्रह के बारे में बात कर रहा है, और आप संग्रह के साथ काम करने के लिए वर्दी इंटरफ़ेस का उपयोग कर सकते हैं (उन सभी को पुनर्प्राप्त करने के लिए प्राप्त करें, उन सभी को हटाने के लिए हटाएं, आदि)

यदि आप इस यूआरएल पर पोस्ट करते हैं, तो आपको "एप्लिकेशन / एक्सएमएल + यूजरकोलेक्शन" दस्तावेज पास करना होगा, जिसमें शायद दस्तावेज़ में केवल एक ही उपयोगकर्ता उदाहरण होगा, ताकि आप उपयोगकर्ता को जोड़ सकें, या नहीं, शायद, कई को जोड़ने के लिए एक बार। शायद आपके दस्तावेज़ीकरण से पता चलता है कि आप संग्रह के बजाय, केवल एक उपयोगकर्ता प्रकार को पास कर सकते हैं।

आप खोज कर सकते हैं कि खोज करने के लिए एप्लिकेशन को क्या चाहिए, जैसा कि "खोज" लिंक द्वारा परिभाषित किया गया है और यह मध्यस्थता है। खोज मीडिया प्रकार के लिए प्रलेखन आपको बताएगा कि यह कैसे व्यवहार करता है, और परिणामों के रूप में क्या उम्मीद करनी है।

यहां ले लिया गया, हालांकि, यूआरआई स्वयं मूल रूप से महत्वहीन हैं। आवेदन यूआरआई के नियंत्रण में है, ग्राहकों को नहीं। कुछ 'प्रवेश बिंदु' से परे, आपके ग्राहकों को अपने काम के लिए आवेदन द्वारा प्रदान किए गए यूआरआई पर भरोसा करना चाहिए।

ग्राहक को यह जानने की जरूरत है कि मीडिया प्रकारों में हेरफेर और व्याख्या कैसे करें, लेकिन जहां यह जाता है, परवाह करने की आवश्यकता नहीं है।

ये दो लिंक एक ग्राहक आंखों में अर्थात् समान हैं:

<link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/>
<link href="http://example.com/AW163FH87SGV" rel="search" type="application/xml+usersearchcriteria"/>

तो, अपने संसाधनों पर ध्यान केंद्रित करें। आवेदन में उनके राज्य संक्रमण पर ध्यान केंद्रित करें और यह कैसे सर्वोत्तम रूप से हासिल किया जाता है।


1. आपको अपने संसाधनों को डिजाइन करने के बारे में सही विचार है, आईएमएचओ। मैं एक चीज़ नहीं बदलूंगा।

2. अधिक क्रियाओं के साथ HTTP का विस्तार करने की कोशिश करने के बजाय, बुनियादी HTTP विधियों और संसाधनों के संदर्भ में आपके प्रस्तावित क्रियाओं को कम किया जा सकता है। उदाहरण के लिए, एक activate_login क्रिया के बजाय, आप संसाधनों को सेट कर सकते हैं जैसे: /api/users/1/login/active जो एक साधारण बूलियन है। लॉगिन को सक्रिय करने के लिए, बस वहां एक दस्तावेज़ PUT जो 'सत्य' या 1 या जो कुछ भी कहता है। निष्क्रिय करने के लिए, वहां एक दस्तावेज़ PUT जो खाली है या 0 या झूठा कहता है।

इसी प्रकार, पासवर्ड बदलने या सेट करने के लिए, बस PUT /api/users/1/password s /api/users/1/password को PUT

जब भी आपको कुछ जोड़ने की आवश्यकता होती है (क्रेडिट की तरह) POST एस के मामले में सोचते हैं। उदाहरण के लिए, आप किसी संसाधन के साथ /api/users/1/credits साथ एक संसाधन में POST कर सकते हैं जिसमें जोड़ने के लिए क्रेडिट की संख्या होती है। एक ही संसाधन पर एक PUT उपयोग मूल्य के बजाय मूल्य को ओवरराइट करने के लिए किया जा सकता है। शरीर में एक नकारात्मक संख्या के साथ एक POST जाएगा, और इसी तरह।

3. मैं बुनियादी HTTP स्टेटस कोड को विस्तारित करने के खिलाफ दृढ़ता से सलाह देता हूं। अगर आपको कोई ऐसी स्थिति नहीं मिलती जो आपकी स्थिति से बिल्कुल मेल खाती है, तो निकटतम को चुनें और प्रतिक्रिया विवरण में त्रुटि विवरण डालें। साथ ही, याद रखें कि HTTP शीर्षलेख एक्स्टेंसिबल हैं; आपका एप्लिकेशन आपको पसंद होने वाले सभी कस्टम शीर्षकों को परिभाषित कर सकता है। एक आवेदन जिसे मैंने काम किया, उदाहरण के लिए, कई परिस्थितियों में 404 Not Found । क्लाइंट को कारण निकाय के कारण प्रतिक्रिया निकाय बनाने के बजाय, हमने अभी एक नया हेडर जोड़ा, X-Status-Extended , जिसमें हमारे मालिकाना स्थिति कोड एक्सटेंशन शामिल थे। तो आप एक प्रतिक्रिया देख सकते हैं जैसे:

HTTP/1.1 404 Not Found    
X-Status-Extended: 404.3 More Specific Error Here

इस तरह एक वेब ब्राउज़र जैसे HTTP क्लाइंट को अभी भी पता चलेगा कि नियमित 404 कोड के साथ क्या करना है, और अधिक परिष्कृत HTTP क्लाइंट अधिक विशिष्ट जानकारी के लिए X-Status-Extended शीर्षलेख को देखने का चयन कर सकता है।

4. प्रमाणीकरण के लिए, यदि आप कर सकते हैं तो HTTP प्रमाणीकरण का उपयोग करने की सलाह देते हैं। लेकिन आईएमएचओ में कुकी-आधारित प्रमाणीकरण का उपयोग करने में कुछ भी गलत नहीं है अगर यह आपके लिए आसान है।


About REST return codes: it is wrong to mix HTTP protocol codes and REST results.

However, I saw many implementations mixing them, and many developers may not agree with me.

HTTP return codes are related to the HTTP Request itself. A REST call is done using a Hypertext Transfer Protocol request and it works at a lower level than invoked REST method itself. REST is a concept/approach, and its output is a business/logical result, while HTTP result code is a transport one.

For example, returning "404 Not found" when you call /users/ is confuse, because it may mean:

  • URI is wrong (HTTP)
  • No users are found (REST)

"403 Forbidden/Access Denied" may mean:

  • Special permission needed. Browsers can handle it by asking the user/password. (HTTP)
  • Wrong access permissions configured on the server. (HTTP)
  • You need to be authenticated (REST)

And the list may continue with '500 Server error" (an Apache/Nginx HTTP thrown error or a business constraint error in REST) or other HTTP errors etc...

From the code, it's hard to understand what was the failure reason, a HTTP (transport) failure or a REST (logical) failure.

If the HTTP request physically was performed successfully it should always return 200 code, regardless is the record(s) found or not. Because URI resource is found and was handled by the http server. Yes, it may return an empty set. Is it possible to receive an empty web-page with 200 as http result, right?

Instead of this you may return 200 HTTP code and simply a JSON with an empty array/object, or to use a bool result/success flag to inform about the performed operation status.

Also, some internet providers may intercept your requests and return you a 404 http code. This does not means that your data are not found, but it's something wrong at transport level.

From Wiki :

In July 2004, the UK telecom provider BT Group deployed the Cleanfeed content blocking system, which returns a 404 error to any request for content identified as potentially illegal by the Internet Watch Foundation. Other ISPs return a HTTP 403 "forbidden" error in the same circumstances. The practice of employing fake 404 errors as a means to conceal censorship has also been reported in Thailand and Tunisia. In Tunisia, where censorship was severe before the 2011 revolution, people became aware of the nature of the fake 404 errors and created an imaginary character named "Ammar 404" who represents "the invisible censor".





rest