2011-07-20 14 views
16

मैंने अभी Restful Web Services और Nobody Understands REST or HTTP पढ़ना समाप्त कर दिया है और एक एपीआई को एक शानदार डिजाइन के साथ डिजाइन करने की कोशिश कर रहा हूं।कोई यूआरआई में 'एपीआई' के साथ एक रीस्टफुल एपीआई क्यों डिजाइन करेगा?

मैं एपीआई यूआरआई डिजाइन में कुछ पैटर्न देखा है:

http://api.example.com/users 
http://example.com/api/users 
http://example.com/users 

मान लें कि इन डिजाइनों ठीक से एक्सएचटीएमएल, JSON, या किसी भी प्रारूप के बीच content negotiations के लिए Accept और Content-type हेडर का उपयोग करें।

इन यूआरआइ एक शुद्ध RESTful कार्यान्वयन बनाम निहित सामग्री बातचीत की बात है क्या?

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

क्या यह सर्वर के पक्ष में संसाधन प्रतिनिधित्व को अलग करने का विषय है?

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

शायद बाहरी उपभोक्ताओं के लिए एक सबडोमेन का उपयोग किया जाता है ताकि सर्वर आंतरिक उपयोग से ओवरहेड से बचा जा सके। दर सीमित?

क्या मुझे कोई बिंदु नहीं है?

मेरे प्रस्तावित डिजाइन, उचित हेडर की स्थापना उचित रूप से HTTP क्रियाओं का उपयोग करके और एक फैशन है कि मैं यूआरआई में 'एपीआई' सहित बेमानी होगा महसूस में संसाधनों के लिए कार्य करके RESTful प्रक्रियाओं का पालन करने का प्रयास करेंगे।

कोई यूआरआई में 'एपीआई' के साथ एक रीस्टफुल एपीआई क्यों डिजाइन करेगा?

या वे कर सकते हैं? हो सकता है कि इस डिजाइन को समझने में मेरी समस्या यह है कि इससे कोई फर्क नहीं पड़ता जब तक यह विनिर्देश के कुछ संयोजन का पालन करता है जो एक वास्तविक API कार्यान्वयन का कारण नहीं बन सकता है लेकिन बंद हो सकता है? कुंजीपटल बिल्ली को त्वचा के एक से अधिक तरीके हैं। HATEOAS संबंधित?


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

उत्तर

5

यह मेरी समझ और अपने प्रश्न के बारे में दृष्टिकोण है:

इन यूआरआई एक शुद्ध RESTful कार्यान्वयन बनाम निहित सामग्री बातचीत की बात है क्या?

नहीं, वे किसी भी आधिकारिक दस्तावेज़ीकरण (जो मुझे पता है) का हिस्सा नहीं हैं, और आमतौर पर डेवलपर/टीम मानकों के विवेकानुसार होते हैं। उदाहरण के लिए, Zend Framework एक्सएचआर अनुरोधों का पता लगाने के लिए कुछ उपयोगिता वर्गों का उपयोग करता है और प्रतिक्रियाओं को कैसे वापस किया जाना चाहिए। अनुमोदित, जेडएफ शुद्ध रीस्टफुल डिज़ाइन (या तथ्य के मामले में अधिकतर PHP अनुप्रयोग) नहीं है, लेकिन PHP में भी ऐसे डिज़ाइन लिखना अभी भी संभव है।

मैंने अक्सर api यूआरएल में उपयोग किया है जब लौटाया गया डेटा वास्तव में उपयोग करने के लिए नहीं है, जैसा कि अंतिम उपयोगकर्ता को प्रदर्शित करने के लिए किया जाता है। हालांकि यह आमतौर पर एक डिजाइन निर्णय होता है और जरूरी नहीं कि एक निहित मानक।

क्या यह सर्वर की तरफ पर संसाधन प्रस्तुतियों को तार्किक रूप से अलग करने का विषय है?

अधिक या कम। उदाहरण के लिए, PUT अनुरोध करते समय, उदाहरण के लिए, इंटरफ़ेस को पूरी तरह से ताज़ा होने की आवश्यकता नहीं होती है, और अक्सर एक साधारण प्रतिक्रिया संदेश पर्याप्त होता है। हालांकि यह प्रतिक्रिया संदेश दृश्य का हिस्सा है, यह दृश्य नहीं है। इसलिए, उदाहरण के लिए, http://domay.com/users/ उपयोगकर्ताओं (या जो भी हो) को प्रबंधित करने के लिए इंटरफ़ेस वापस कर देगा, http://domain.com/users/api संचालन करेगा और इंटरफ़ेस अपडेट लौटाएगा (पृष्ठ रीलोड के बिना)।

क्या मुझे कोई बिंदु नहीं है?

वेल्ल, नहीं। चूंकि यह यूआरएल में api का उपयोग करने का डिज़ाइन निर्णय है या नहीं, तो आप यहां कुछ भी नहीं खो रहे हैं।उचित शीर्षलेखों के साथ,

http://domain.com/users/api/get 
http://domain.com/users/get 
http://domain.com/users/ 

सभी मान्य रीस्टफुल अनुरोध हो सकते हैं।

कोई यूआरआई में 'एपीआई' के साथ एक रीस्टफुल एपीआई क्यों डिजाइन करेगा?

बस यूआरएल नामकरण सम्मेलन रखने के लिए कहें। इसलिए, जब लॉग, दस्तावेज, आदि में एक अनुरोध को देखते समय कोई इसका उद्देश्य समझ जाएगा।

11

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

5

यह भी ध्यान रखें कि अधिकांश ढांचे (डीजेंगो, आरओआर, ...) बॉक्स से यूआरएल-आधारित रूटिंग प्रदान करते हैं। प्रमाणीकरण, ट्रॉटिंग, सीमा-जांच और अन्य विशिष्ट सामान जैसे चीजों को प्रबंधित करने के लिए आपको शायद एपीआई बनाम एचटीएमएल प्रतिक्रियाओं के लिए अलग-अलग विचारों की आवश्यकता है।

एक अतिरिक्त HTTP-शीर्षलेख आधारित रूटिंग सिस्टम को स्थानांतरित करने के लिए, जैसा कि आप कहते हैं, अंतर्निहित सामग्री वार्ता अक्सर प्रयास के लायक नहीं है।

4

उपयोगकर्ता-दिखाई वेबपृष्ठ URL, एक एपीआई वेबमास्टर्स, डिजाइनरों, कॉर्पोरेट संगठन, विपणन, फैशन, प्रौद्योगिकी की सनक के अधीन हैं आदि

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

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