मानक JSON एपीआई प्रतिक्रिया प्रारूप?

Question

क्या एपीआई से JSON प्रतिक्रियाओं को संरचित करने के लिए मानक या सर्वोत्तम प्रथाएं मौजूद हैं? जाहिर है, हर एप्लिकेशन का डेटा अलग-अलग होता है, इसलिए कि मैं इससे चिंतित नहीं हूं, बल्कि "प्रतिक्रिया बॉयलरप्लेट", यदि आप करेंगे। मेरा क्या मतलब है इसका एक उदाहरण:

सफल अनुरोध:

{
  "success": true,
  "payload": {
    /* Application-specific data would go here. */
  }
}

असफल अनुरोध:

{
  "success": false,
  "payload": {
    /* Application-specific data would go here. */
  },
  "error": {
    "code": 123,
    "message": "An error occurred!"
  }
}

Comments

लोगों ने शायद SOAP से सीखा है और इसे फिर से नहीं बनाएंगे ...

— Denys Séguret

@ डायस्ट्रो: आपकी टिप्पणी को समझाने के लिए देखभाल?

— FtDRbwLXw6

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

— एलेक्स

@ दुर्भाग्य से, ऐसा इसलिए है क्योंकि आप जहां भी जाते हैं, कोई मानक नहीं है। केवल JSON के भीतर ही नहीं, बल्कि Restful एप्लिकेशन या सॉर्ट के कुछ और के लिए इसका उपयोग कैसे करें के संदर्भ में। हर कोई इसे अलग तरह से करता है। आप सर्वोत्तम प्रथाओं (HTTP- प्रतिक्रियाओं, सार्थक पैकेज-संरचना, आपके सिस्टम द्वारा खपत के लिए अपने डेटा को संरचित करने की एक आँख) का अनुसरण करने के लिए स्वतंत्र महसूस कर सकते हैं, लेकिन हर कोई जो एक प्रमुख वितरक है, वह दूसरों की तुलना में कम से कम एक काम कर रहा है। .. कोई मानक नहीं है, और वहाँ एक होने की संभावना नहीं होगी, इसलिए कुछ ठोस बनाएं, और आपको फिट करने के लिए इसका निर्माण करें।

— नोरगार्ड

@Norguard मानक हैं (मेरा उत्तर देखें)। वास्तव में मानकों के बारे में अच्छी बात यह है कि आपके पास चुनने के लिए बहुत सारे हैं। - एंड्रयू टेनबाम

— एडम जेंट

Answer 1

हाँ, कुछ मानक हैं (जो मानक की परिभाषा पर कुछ स्वतंत्रताएँ प्रदान करते हैं) जो सामने आए हैं:

1. JSON API - JSON API संसाधनों को बनाने और अद्यतन करने के साथ-साथ प्रतिक्रियाएं भी शामिल करता है।
2. JSend - सरल और शायद आप पहले से ही क्या कर रहे हैं।
3. OData JSON प्रोटोकॉल - बहुत जटिल है।
4. HAL - ओडटा की तरह लेकिन HATEOAS होने का लक्ष्य ।

JSON API विवरण प्रारूप भी हैं:

• अकड़
  • JSON स्कीमा (स्वैगर द्वारा उपयोग किया जाता है लेकिन आप इसे अकेले ही उपयोग कर सकते हैं)
• JAD में WADL
• Raml
• HAL क्योंकि सिद्धांत में HATEOAS आत्म वर्णन है।

Comments

धन्यवाद। विशेष रूप से JSend बिल्कुल वही है जिसकी मुझे तलाश थी। यह वैसा ही है जैसा मैं कर रहा था, लेकिन इसके कुछ फायदे हैं जो मेरे तरीके में नहीं थे। @Trungly की निष्पक्षता में, JSend अपने स्वयं के उत्तर के बहुत करीब है, साथ ही साथ।

— FtDRbwLXw6

त्रुटि प्रतिक्रियाओं के लिए विशेष रूप से मुझे HTTP APIs RFC ड्राफ्ट के लिए समस्या विवरण भी पसंद है ।

— पीटर एन्स

शायद आप विवरण प्रारूप सूची में code.google.com/p/json-service जोड़ना चाहते हैं ?

— इमिलेसिल्विस

मुझे लगता है कि "रेल के लिए एक अनुशंसित मानक" लेबल एक ओवरस्टेटमेंट का एक सा है - यह सिर्फ एक प्रोग्रामर का समाधान है। निश्चित नहीं है कि यह एक "अनुशंसित मानक" क्या है (विशेषकर यदि आप मणि की लोकप्रियता को देखते हैं - ऐसा नहीं लगता है कि बहुत से लोग इसका उपयोग कर रहे हैं)? मुझे नहीं लगता कि अधिकांश रेल प्रोग्रामर इस समाधान की सिफारिश करेंगे क्योंकि स्थिति के लिए HTTP हेडर के बजाय प्रतिक्रिया शरीर का उपयोग करने के लिए

— Iwo Dziechciarow

Google JSON स्टाइल गाइड भी एक अच्छा संदर्भ है

— MRodrigues

Answer 2

Google JSON गाइड

सफलता प्रतिक्रिया data

{
  "data": {
    "id": 1001,
    "name": "Wing"
  }
}

त्रुटि प्रतिक्रिया error

{
  "error": {
    "code": 404,
    "message": "ID not found"
  }
}

और यदि आपका ग्राहक जेएस है, तो आप if ("error" in response) {}जांच कर सकते हैं कि क्या कोई त्रुटि है।

Comments

सबसे पहले, Google JSON गाइड एकल उद्धरणों के बजाय दोहरे उद्धरण चिह्नों का उपयोग करने की सलाह देता है।

— rpozarickij

यकीन नहीं है कि अगर आप PlayJson जैसे सर्वर साइड JSON एपीआई से इसे संभाल सकते हैं, तो किसी भी तरह से कोई फर्क नहीं पड़ता। @ सच में आपके लिंक टूट गए हैं

— Rhys ब्रैडबरी

उन त्रुटियों के बारे में जो असफलताओं की सूची प्रदान करने की आवश्यकता है (जैसे सत्यापन समस्याएं)?

— एक्सोनक्रॉस

@Xeoncross शब्द पर लिंक पर क्लिक करें error, Google का पृष्ठ इस बात का उदाहरण देता है

— MI राइट

@Xeoncross आप error.errors [] का उपयोग करके विफलताओं की एक सूची वापस कर सकते हैं, जैसा कि परिभाषित किया गया है: "त्रुटि के संबंध में किसी भी अतिरिक्त जानकारी के लिए कंटेनर। यदि सेवा में कई त्रुटियाँ हैं, तो त्रुटि सरणी में प्रत्येक तत्व एक अलग त्रुटि का प्रतिनिधित्व करता है।" शायद शीर्ष स्तर की त्रुटि "रिक्वेस्ट फेल इनपुट वेलिडेशन" का उल्लेख करेगी और त्रुटियों [] एरे में प्रत्येक विशिष्ट वेलिडेशन विफलता के लिए एक प्रविष्टि होगी।

— जेम्स डेली

Answer 3

मुझे लगता है कि एक डिफैक्टो मानक वास्तव में उभरा नहीं है (और शायद कभी नहीं)। लेकिन परवाह किए बिना, यहाँ मेरा लेना है:

सफल अनुरोध:

{
  "status": "success",
  "data": {
    /* Application-specific data would go here. */
  },
  "message": null /* Or optional success message */
}

असफल अनुरोध:

{
  "status": "error",
  "data": null, /* or optional error payload */
  "message": "Error xyz has occurred"
}

लाभ: सफलता और त्रुटि दोनों मामलों में समान स्तर के तत्व

नुकसान: कोई त्रुटि कोड नहीं है, लेकिन यदि आप चाहते हैं, तो आप स्थिति को (सफलता या विफलता) कोड होने के लिए बदल सकते हैं, -या- आप "कोड" नामक एक और शीर्ष-स्तरीय आइटम जोड़ सकते हैं।

Comments

हाँ, यह सही तरीका है अगर आप POJO को json पार्सिंग के लिए उपयोग कर रहे हैं! जब हम POJOs का उपयोग कर रहे हैं, तो हमें स्थिर, गैर गतिशील json प्रारूप की आवश्यकता है!

— LOG_TAG

सरल और सटीक। मेरी राय में jsend से बेहतर है क्योंकि jsend त्रुटि को असफलता से अलग करता है।

— जोस अलेक्जेंडर इबारा

मैं इस पैटर्न का भी उपयोग करता हूं, लेकिन एक फ़ील्ड के साथ, messagesजो एकल स्ट्रिंग के बजाय संदेशों की एक सरणी है।

— स्टॉकब्रीक

जवाब लगभग अच्छी तरह से प्रलेखित JSend की एक प्रति है जो सरल और बहुत उपयोगी है। उन्होंने failविशिष्ट सत्यापन समस्याओं के लिए तीसरी स्थिति प्रदान की , जबकि errorडीबी त्रुटियों की तरह केवल वसा के साथ प्रयोग किया जाता है।

— s3m3n

सफलता के लिए: यदि यह 200हेडर में है, तो आपको statusफ़ील्ड की आवश्यकता क्यों है ? बस डेटा ऑब्जेक्ट को सीधे लौटाएं। आप जानते हैं कि यह टाइपस्क्रिप्ट FE भाषाओं जैसे टाइपस्क्रिप्ट के साथ अतिरिक्त दर्द पैदा कर सकता है।

— डेनिस एम।

Answer 4

आपको लगता है कि सवाल REST webservices डिजाइन और अधिक सफलता / त्रुटि के विषय में है।

मुझे लगता है कि डिजाइन के 3 अलग-अलग प्रकार हैं।

1. यदि कोई त्रुटि थी, तो यह इंगित करने के लिए केवल HTTP स्थिति कोड का उपयोग करें और अपने आप को मानक लोगों तक सीमित करने का प्रयास करें (आमतौर पर यह पर्याप्त होना चाहिए)।

   • पेशेवरों: यह आपके एपीआई से स्वतंत्र मानक है।
   • विपक्ष: वास्तव में क्या हुआ, इसकी कम जानकारी।

2. उपयोग HTTP स्थिति + json शरीर (भले ही यह एक त्रुटि है)। त्रुटियों के लिए एक समान संरचना को परिभाषित करें (उदा: कोड, संदेश, कारण, प्रकार, आदि) और त्रुटियों के लिए इसका उपयोग करें, यदि यह एक सफलता है तो बस अपेक्षित जसन प्रतिक्रिया लौटाएं।

   • पेशेवरों: अभी भी मानक के रूप में आप मौजूदा HTTP स्थिति कोड का उपयोग करते हैं और आप त्रुटि का वर्णन करते हुए एक जसन लौटाते हैं (आप जो हुआ उस पर अधिक जानकारी प्रदान करते हैं)।
   • विपक्ष: यदि यह एक त्रुटि या सफलता है, तो आउटपुट जसन अलग-अलग होगा।

3. Http स्थिति (उदा: हमेशा स्थिति 200) को भूल जाएं , हमेशा json का उपयोग करें और प्रतिक्रिया के मूल में एक बूलियन उत्तर जोड़ें (success) आबाद हैं।

   • पेशेवरों: ग्राहक केवल प्रतिक्रिया के शरीर के साथ व्यवहार करता है जो कि एक जस स्ट्रिंग है और स्थिति (?) को अनदेखा करता है।

   • विपक्ष: कम मानक।

यह आपको चुनना है :)

एपीआई पर निर्भर करता है कि मैं 2 या 3 का चयन करूंगा (मुझे json rest apis के लिए 2 पसंद है)। REST Api को डिजाइन करने में एक और चीज जो मैंने अनुभव की है, वह है प्रत्येक संसाधन (url) के लिए प्रलेखन का महत्व: पैरामीटर, निकाय, प्रतिक्रिया, हेडर आदि + उदाहरण।

मैं आपको जर्सी (jax-rs कार्यान्वयन) + गेंसन (जावा / json डेटाबाइंडिंग लाइब्रेरी) का उपयोग करने की भी सलाह दूंगा । आपको केवल अपने क्लासपैथ में गेंसन + जर्सी को गिराना होगा और json स्वचालित रूप से समर्थित है।

संपादित करें:

• समाधान 2 को लागू करना सबसे कठिन है, लेकिन इसका फायदा यह है कि आप अपवादों को अच्छी तरह से संभाल सकते हैं और न केवल व्यावसायिक त्रुटियों को देखते हैं, प्रारंभिक प्रयास अधिक महत्वपूर्ण है, लेकिन आप लंबे समय तक जीतते हैं।

• समाधान 3, सर्वर साइड और क्लाइंट दोनों पर लागू करना आसान है, लेकिन यह इतना अच्छा नहीं है क्योंकि आपको उन ऑब्जेक्ट्स को एनकैप्सुलेट करना होगा जिन्हें आप एक प्रतिक्रिया ऑब्जेक्ट में वापस करना चाहते हैं, जिसमें responseValid + त्रुटि भी है।

Comments

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

— FtDRbwLXw6

रिकॉर्ड के लिए: HTTP स्थिति कोड हेडर नहीं है।

— पेप्किन p

"प्रतिक्रिया json नहीं बल्कि html होगी।" गलत! html का एरर हैंडलिंग से कोई लेना-देना नहीं है। प्रतिक्रिया हो सकती है जो कुछ भी सामग्री-प्रकार आप समर्थन करते हैं।

— ऑलिगॉफ्रेन

@ @ Code ッ ク ア HTTP स्थिति कोड एक HTTP प्रतिक्रिया के शीर्ष लेख की स्थिति रेखा में 3 अंकों का कोड है। उस पंक्ति के बाद शीर्ष लेख फ़ील्ड हैं, बोलचाल को हेडर भी कहा जाता है।

— पेप्किन p

@ @ Page ッ ク ely HTTP पर विकिपीडिया पेज आपके सवालों के अच्छे से उत्तर देता है, आप इसे वहां देख सकते हैं: en.wikipedia.org/wiki/… (अनुभाग प्रतिक्रिया संदेश से लिंक)

— pepkin88

Answer 5

आरएफसी 7807: HTTP API के लिए समस्या विवरण पल में निकटतम बात हम एक आधिकारिक मानक करने के लिए है है।

Comments

3 साल बाद ... जाने की दिशा प्रतीत हो रही है। इसे भी देखें: youtu.be/vcjj5pT0bSQ?t=611 (7807 के लिए विजुअल स्टूडियो .Net कोर सपोर्ट)

— एडेलवाटर

Answer 6

बाद json प्रारूप इंस्टाग्राम का उपयोग कर रहा है

{
    "meta": {
         "error_type": "OAuthException",
         "code": 400,
         "error_message": "..."
    }
    "data": {
         ...
    },
    "pagination": {
         "next_url": "...",
         "next_max_id": "13872296"
    }
}

Answer 7

मैं यह दावा करने के लिए उतना अभिमानी नहीं होऊंगा कि यह एक मानक है इसलिए मैं "मैं पसंद करता हूं" फॉर्म का उपयोग करूंगा।

मैं ट्रिक रिस्पांस पसंद करता हूं (जब मैं उन लेखों की सूची का अनुरोध करूं / जिन्हें मैं JSON सरणी लेख चाहता हूं)।

अपने डिजाइनों में मैं स्टेटस रिपोर्ट के लिए HTTP का उपयोग करता हूं, एक 200 पेलोड का रिटर्न देता है।

400 अनुरोध के साथ क्या गलत था का एक संदेश देता है:

{"message" : "Missing parameter: 'param'"}

यदि मॉडल / कंट्रोलर / URI मौजूद नहीं है तो 404 लौटें

यदि मेरी ओर से प्रसंस्करण में त्रुटि थी, तो मैं 501 को संदेश के साथ लौटाता हूं :

{"message" : "Could not connect to data store."}

जो कुछ मैंने देखा है उससे कुछ REST-ish रूपरेखाएँ इन पंक्तियों के साथ होती हैं।

औचित्य :

JSON को पेलोड प्रारूप माना जाता है , यह सत्र प्रोटोकॉल नहीं है। वर्बोज़ सत्र-ईश पेलोड्स का पूरा विचार XML / SOAP दुनिया और विभिन्न गुमराह विकल्पों से आता है जिन्होंने उन फूला हुआ डिजाइनों का निर्माण किया। बाद हमने महसूस किया कि यह सभी को एक बड़े पैमाने पर सिर दर्द, बाकी के पूरे मुद्दे था / JSON यह, और पालन करने के लिए HTTP चुम्बन करने के लिए किया गया था। मुझे नहीं लगता कि जेएसएंड में कुछ भी दूरस्थ रूप से मानक है और विशेष रूप से उनके बीच अधिक क्रिया के साथ नहीं है। यदि आप अपने AJAX के लिए jQuery का उपयोग करते हैं (जैसे अधिकांश करते हैं) तो XHR HTTP प्रतिक्रिया पर प्रतिक्रिया देगा, आप त्रुटियों को पकड़ने के लिए try/ catchऔर done()/ fail()कॉलबैक का उपयोग कर सकते हैं। मैं यह नहीं देख सकता कि JSON में स्टेटस रिपोर्ट कितनी आसान है।

Comments

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

— डिर्क बेस्टर

शायद मुझे इसे "एक पेलोड प्रारूप माना जाना चाहिए" के रूप में तैयार किया जाना चाहिए, लेकिन इसके अलावा, मैं अपनी टिप्पणी के साथ खड़ा हूं। आप HTML दस्तावेज़ में बॉडी टैग की विशेषताओं के रूप में सत्र / त्रुटि डेटा डाल सकते हैं , लेकिन यह इसे करने का सही या समझदार तरीका नहीं बनाता है।

— बोजान मार्कोविच

Answer 8

इसके लायक मैं इसके लिए अलग तरीके से काम करता हूं। एक सफल कॉल में सिर्फ JSON ऑब्जेक्ट हैं। मुझे एक उच्च स्तर की JSON ऑब्जेक्ट की आवश्यकता नहीं है जिसमें एक सफल फ़ील्ड है जो सच को दर्शाता है और एक पेलोड फ़ील्ड जिसमें JSON ऑब्जेक्ट है। मैं सिर्फ हेडर में HTTP स्टेटस के लिए 200 की रेंज में जो भी उपयुक्त हो JSON ऑब्जेक्ट को वापस करता हूं।

हालाँकि, अगर कोई त्रुटि है (400 परिवार में कुछ) मैं एक अच्छी तरह से बनाई गई JSON त्रुटि ऑब्जेक्ट वापस करता हूं। उदाहरण के लिए, यदि ग्राहक एक ईमेल पते और फोन नंबर के साथ एक उपयोगकर्ता पोस्ट कर रहा है और इनमें से एक विकृत है (यानी मैं इसे अपने अंतर्निहित डेटाबेस में सम्मिलित नहीं कर सकता) तो मैं कुछ इस तरह वापस आऊंगा:

{
  "description" : "Validation Failed"
  "errors" : [ {
    "field" : "phoneNumber",
    "message" : "Invalid phone number."
  } ],
}

यहाँ महत्वपूर्ण बिट्स हैं कि "फ़ील्ड" संपत्ति को JSON फ़ील्ड से बिल्कुल मेल खाना चाहिए, जिसे मान्य नहीं किया जा सकता है। यह ग्राहकों को यह जानने की अनुमति देता है कि उनके अनुरोध के साथ क्या गलत हुआ। इसके अलावा, "संदेश" अनुरोध के स्थान पर है। यदि दोनों "emailAddress" और "phoneNumber" अमान्य थे, तो "त्रुटियों" सरणी में दोनों के लिए प्रविष्टियाँ होंगी। 409 (संघर्ष) JSON प्रतिक्रिया निकाय इस तरह दिख सकता है:

{
  "description" : "Already Exists"
  "errors" : [ {
    "field" : "phoneNumber",
    "message" : "Phone number already exists for another user."
  } ],
}

HTTP स्टेटस कोड और इस JSON क्लाइंट के पास वे सभी हैं जो उन्हें एक नियत तरीके से त्रुटियों का जवाब देने की आवश्यकता है और यह एक नया त्रुटि मानक नहीं बनाता है जो HTTP स्थिति कोड को बदलने का प्रयास करता है। ध्यान दें, ये केवल 400 त्रुटियों की सीमा के लिए होते हैं। 200 रेंज में किसी भी चीज के लिए मैं सिर्फ वही वापस कर सकता हूं जो उपयुक्त है। मेरे लिए यह अक्सर एक HAL की तरह JSON ऑब्जेक्ट है, लेकिन वास्तव में यहाँ कोई फर्क नहीं पड़ता।

जोड़ने के बारे में मैंने जो सोचा था वह एक संख्यात्मक त्रुटि कोड था या तो "त्रुटियों" सरणी प्रविष्टियों या स्वयं JSON ऑब्जेक्ट की जड़ में। लेकिन अभी तक हमें इसकी जरूरत नहीं है।

Answer 9

बड़े सॉफ्टवेयर दिग्गजों - गूगल, फेसबुक, ट्विटर, अमेज़ॅन और अन्य के बाकी एपीआई प्रतिक्रिया प्रारूपों पर उनका कोई समझौता नहीं है, हालांकि ऊपर दिए गए उत्तरों में कई लिंक प्रदान किए गए हैं, जहां कुछ लोगों ने प्रतिक्रिया प्रारूप को मानकीकृत करने की कोशिश की है।

चूंकि एपीआई की ज़रूरतें अलग-अलग हो सकती हैं, इसलिए सभी को बोर्ड पर लाना और कुछ प्रारूप के लिए सहमत होना बहुत मुश्किल है। यदि आपके पास आपके API का उपयोग करने वाले लाखों उपयोगकर्ता हैं, तो आप अपना प्रतिसाद प्रारूप क्यों बदलेंगे?

Google, ट्विटर, अमेज़ॅन और इंटरनेट पर कुछ पोस्टों से प्रेरित प्रतिक्रिया प्रारूप पर निम्नलिखित है:

https://github.com/adnan-kamili/rest-api-response-format

स्वैगर फ़ाइल:

https://github.com/adnan-kamili/swagger-sample-template

Comments

लिफाफा मुक्त बाकी-api-प्रतिक्रिया-स्वरूप के लिए वोट दें

— Kerem Baydoğan

@adnan kamilli - >>> StatusCode: 304, ReasonPhrase: 'Not Modified', संस्करण: 1.1, सामग्री: <null>, Headers: {} <<<< क्या यह restApi की उचित प्रतिक्रिया है?

— अर्नोल्ड ब्राउन

@AnnoldBrown किस एपीआई के लिए एंडपॉइंट - कार्रवाई आप इस कोड को वापस कर रहे हैं?

— अदनान कामिली

एक छवि (प्रपत्र डेटा) अपलोड करने के लिए उपयोग किए गए एक एपीआई की प्रतिक्रिया रिटर्न - क्लाइंट लिखित एपीआई।

— अर्नाल्ड ब्राउन

Answer 10

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

रूटनोड का प्रकार आपके ऊपर क्या है, इसमें क्या है, यह आपके ऊपर है, क्या आप मेटाडेटा भेजते हैं, साथ ही प्रतिक्रिया आपके ऊपर है, चाहे आप माइम-प्रकार सेट करें application/jsonया इसे छोड़ दें जैसा text/plainकि आप पर निर्भर है ( जब तक आप जानते हैं कि किनारे के मामलों को कैसे संभालना है)।

एक हल्के स्कीमा का निर्माण करें जो आपको पसंद हो।
व्यक्तिगत रूप से, मैं पाया है कि एनालिटिक्स ट्रैकिंग और एमपी 3 / ogg की सेवा और छवि गैलरी की सेवा और पाठ-संदेश सेवा और ऑनलाइन गेमिंग के लिए नेटवर्क के पैकेट, और ब्लॉग-पोस्ट और ब्लॉग टिप्पणी सब है बहुत अलग आवश्यकताओं है क्या करने के मामले में भेजा गया और क्या प्राप्त हुआ और उन्हें कैसे खाया जाना चाहिए।

तो आखिरी चीज जो मैं चाहूंगा, वह सब करते हुए, हर एक को उसी बॉयलरप्लेट मानक के अनुरूप बनाने की कोशिश करना है, जो XML2.0 या सोमेसच पर आधारित है।

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

Comments

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

— FtDRbwLXw6

या तो सब कुछ के लिए 200 की स्थिति लौटाएं, और अपने आप को एक विशिष्ट त्रुटि पेलोड को परिभाषित करें, या पेलोड के शरीर में अधिक विवरण के साथ, और / या बिना त्रुटि के साथ स्थिति की वापसी करें (यदि समर्थित है)। जैसा कि मैंने कहा, स्कीमा आपके ऊपर है - किसी भी मेटा / स्थिति की जानकारी सहित। यह एक 100% रिक्त स्लेट है जिसे आप अपनी पसंदीदा शैली की वास्तुकला के आधार पर करते हैं।

— नोरगार्ड

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

— FtDRbwLXw6

Answer 11

JSON-RPC 2.0 एक मानक अनुरोध और प्रतिक्रिया प्रारूप को परिभाषित करता है, और REST एपीआई के साथ काम करने के बाद ताजी हवा की एक सांस है।

Comments

अपवाद के लिए केवल JSON-RPC_2.0 ऑफ़र एक त्रुटि कोड है? एक संख्यात्मक त्रुटि कोड किसी भी निष्ठा समस्या के साथ प्रतिनिधित्व नहीं कर सकता है जो हुई।

— एजिलेप्रो

@ एगिलप्रो सहमत, एक संख्यात्मक त्रुटि कोड बहुत अच्छा नहीं है, और मैं चाहता हूं कि कल्पना के लेखकों ने codeक्षेत्र को एक स्ट्रिंग होने की अनुमति दी थी । सौभाग्य से ऐनक हमें त्रुटि के dataक्षेत्र में जो भी जानकारी चाहिए, उसे सामान करने की अनुमति देता है । मेरी JSON-RPC परियोजनाओं में मैं आमतौर पर सभी अनुप्रयोग-परत त्रुटियों के लिए एक एकल संख्यात्मक कोड का उपयोग करता हूं (जैसा कि मानक प्रोटोकॉल में से एक के विपरीत)। फिर मैंने विस्तृत त्रुटि जानकारी ( dataफ़ील्ड में वास्तविक त्रुटि प्रकार को इंगित करने वाला एक स्ट्रिंग कोड सहित) डाल दी ।

— dnault

Answer 12

बाद में आने वालों के लिए, स्वीकृत उत्तर के अलावा, जिसमें एचएएल, जेएसएंड और जेएसएन एपीआई शामिल हैं, मैं कुछ अन्य विशिष्टताओं को ध्यान में रखते हुए जोड़ूंगा:

• JSON-LD , जो W3C अनुशंसा है और निर्दिष्ट करता है कि JSON में इंटरऑपरेबल वेब सेवाओं का निर्माण कैसे किया जाए
• रेस्ट के लिए आयन हाइपरमीडिया टाइप , जो खुद को "रेस्ट के लिए एक सरल और सहज JSON- आधारित हाइपरमीडिया प्रकार" के रूप में दावा करता है।

Answer 13

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

मैंने थोड़ी खोजबीन की और पाया कि रिटर्निंग एरर (अपवाद) के लिए सबसे सामान्य प्रारूप इस फॉर्म की एक संरचना है:

{
   "success": false,
   "error": {
      "code": "400",
      "message": "main error message here",
      "target": "approx what the error came from",
      "details": [
         {
            "code": "23-098a",
            "message": "Disk drive has frozen up again.  It needs to be replaced",
            "target": "not sure what the target is"
         }
      ],
      "innererror": {
         "trace": [ ... ],
         "context": [ ... ]
      }
   }
}

यह OASIS डेटा मानक OASIS OData द्वारा प्रस्तावित प्रारूप है और लगता है कि वहाँ सबसे मानक विकल्प है, हालाँकि इस बिंदु पर किसी भी मानक की उच्च गोद लेने की दरें प्रतीत नहीं होती हैं। यह प्रारूप JSON-RPC विनिर्देशन के अनुरूप है।

आप पूरा खुला स्रोत पुस्तकालय पा सकते हैं जो इस पर लागू होता है: मेंडोकिनो जोंस यूटिलिटीज । यह लाइब्रेरी JSON ऑब्जेक्ट्स के साथ-साथ अपवादों का समर्थन करती है।

JSON REST API में एरर हैंडलिंग पर मेरे ब्लॉग पोस्ट में विवरण की चर्चा की गई है

Answer 14

सामान्य ज्ञान के अलावा कोई नियम-कानून या गैरकानूनी मानक नहीं है। यदि हम दो लोगों से बात करते हुए इसे अमूर्त करते हैं, तो मानक सबसे अच्छा तरीका है जिससे वे न्यूनतम समय में एक दूसरे को सही शब्दों में समझ सकें। हमारे मामले में, 'न्यूनतम शब्द' परिवहन दक्षता के लिए बैंडविड्थ का अनुकूलन कर रहा है और 'सटीक रूप से समझने' के लिए पार्सर दक्षता के लिए संरचना है; जो अंततः कम डेटा, और सामान्य संरचना के साथ समाप्त होता है; इतना है कि यह एक पिन छेद के माध्यम से जा सकता है और एक सामान्य दायरे (कम से कम शुरू में) के माध्यम से पार्स किया जा सकता है।

लगभग हर मामले में सुझाव दिया गया है, मैं 'सफलता' और 'त्रुटि' परिदृश्य के लिए अलग-अलग प्रतिक्रियाएं देख रहा हूं, जो मेरे लिए अस्पष्टता की तरह है। अगर इन दोनों मामलों में प्रतिक्रियाएं अलग-अलग हैं, तो हमें वास्तव में वहां 'सफलता' का झंडा लगाने की क्या जरूरत है? क्या यह स्पष्ट नहीं है कि 'त्रुटि' की अनुपस्थिति एक 'सफलता' है? क्या यह संभव है कि एक 'एरर' सेट के साथ 'सक्सेस' ट्राय हो, जहां एक प्रतिक्रिया हो। या रास्ता, 'सफलता' FALSE है जिसमें कोई 'त्रुटि' सेट नहीं है? सिर्फ एक झंडा ही काफी नहीं है? मैं केवल 'त्रुटि' ध्वज रखना पसंद करूंगा, क्योंकि मेरा मानना ​​है कि 'सफलता' की तुलना में 'त्रुटि' कम होगी।

साथ ही, क्या हमें वास्तव में 'त्रुटि' को ध्वज बनाना चाहिए? यदि मैं कई सत्यापन त्रुटियों के साथ जवाब देना चाहता हूं तो क्या होगा? इसलिए, मुझे उस नोड के लिए बच्चे के रूप में प्रत्येक त्रुटि के साथ 'त्रुटि' नोड होना अधिक कुशल लगता है; जहाँ एक खाली (शून्य पर गिना जाता है) 'त्रुटि' नोड एक 'सफलता' को दर्शाता है।

Answer 15

वेब एप के लिए सर्वश्रेष्ठ प्रतिक्रिया जो मोबाइल डेवलपर्स द्वारा आसानी से समझ सकते हैं।

यह "सक्सेस" रिस्पॉन्स के लिए है

{  
   "ReturnCode":"1",
   "ReturnMsg":"Successfull Transaction",
   "ReturnValue":"",
   "Data":{  
      "EmployeeName":"Admin",
      "EmployeeID":1
   }
}

यह "त्रुटि" प्रतिक्रिया के लिए है

{
    "ReturnCode": "4",
    "ReturnMsg": "Invalid Username and Password",
    "ReturnValue": "",
    "Data": {}
}

Comments

बेहतर होगा कि अपने गुणों का मानकीकरण करें। वे सभी "रिटर्न ..." मान हैं। लेकिन डेटा उपसर्ग नहीं है। मैं कहता हूँ, सभी "रिटर्न" उपसर्गों को छोड़ दें।

— z0mbi3

"रिटर्न" सहित सुंदर अतिरेक भी है।

— जैक मार्शेटी