PHP और कस्टम HTTP शीर्षलेख, खराब अभ्यास?

Question

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

सवाल यह है कि क्या इस समस्या का उपयोग करने के बारे में मुझे कोई कमी नहीं हुई है? अनुप्रयोगों के लिए कस्टम http शीर्षलेख सेट करने के लिए यह बहुत आम प्रतीत नहीं होता है, इसलिए मैं सोच रहा हूं कि यह किसी भी तरह का खराब अभ्यास या बुरा "स्वाद" है।

Answer 1

यह एक दिलचस्प सवाल है। इसके लिए कोई समस्या नहीं होनी चाहिए, लेकिन आपको कुछ चीजों को ध्यान में रखना चाहिए:

1. हेडर को आपके एप्लिकेशन के लिए अद्वितीय होना चाहिए। अभी नहीं, बल्कि हमेशा के लिए। आपको यह सुनिश्चित करना चाहिए कि आप उन्हें उपसर्ग कर रहे हैं, उदा। X-MyApplication-Foo: Bar। ऐसा करने से भविष्य में संघर्ष हो सकता है।
   
   
2. फ़ायरवॉल कभी-कभी (शायद ही कभी) अज्ञात HTTP शीर्षलेख फ़िल्टर करने के साथ थोड़ा अति उत्साही है। यह कोई समस्या नहीं होनी चाहिए, लेकिन यह ध्यान में रखना कुछ है।
   
   
3. पुराने ब्राउज़रों के पास आधुनिक ब्राउज़र की तुलना में हेडर फ़ील्ड आकारों पर छोटी सीमाएं होती हैं, इसलिए आपको जितना हो सके उतना परीक्षण करना होगा।
   
   

कारण आप मानक HTTP त्रुटि कोड्स उपयोग नहीं कर सकते हैं है? मैं समझता हूं कि आप स्टैक निशान या अन्य उपयोगी डीबगिंग जानकारी प्रदान करना चाहते हैं, लेकिन किसी त्रुटि के मामले में, क्या आप सामान्य "परिणाम" JSON डेटा की बजाय त्रुटि जानकारी वाले JSON ब्लॉब को वापस नहीं करेंगे? आप आसानी से HTTP त्रुटि कोड के आधार पर अंतर का पता लगा सकते हैं और दो मामलों को अलग-अलग संभाल सकते हैं।

कारण मैं आपके सुझाए गए दृष्टिकोण से चिंतित हूं कि हेडर का उपयोग ब्राउज़र व्यवहार को बदलने या कारण बनाने के लिए किया जाता है - वे डेटा स्टोरेज तंत्र होने का इरादा नहीं रखते हैं।

छद्म कोड उदाहरण:

switch(httpResponseCode) 
{ 
    case 200: 
     parseResult(json); 
     break; 
    case 403: 
     parseForbidden(json); 
     break; 
    case 500: 
     parseServerError(json); 
     break; 
    default: 
     // bad response code, handle appropriately 
}