rest - खनिज तथा ऊर्जा संसाधन क्लास १०




आरईएसटी एपीआई संस्करण(केवल प्रतिनिधित्व का संस्करण, संसाधन स्वयं नहीं) (5)

मैंने एपीआई संस्करण के लिए सर्वश्रेष्ठ प्रथाओं पर एक नज़र डाली थी? , लेकिन मैं जवाब के बारे में पूरी तरह से आश्वस्त नहीं हूं, इसलिए मैं एक और विशिष्ट उदाहरण के साथ संस्करण संस्करण फिर से सवाल कर रहा हूं। मेरे पास दो यूआरआई हैं (एक यूआरआई के हिस्से के रूप में संस्करण के साथ और बिना किसी के):

http://xxxx/v1/user/123    -> favored solution in discussed thread
http://xxxx/user/123             

मुझे संदेह है कि पहला लिंक आरईएसटी के विचार को व्यक्त करता है। मुझे http://xxxx/v1/user/123 भ्रमित लगता है क्योंकि यह सुझाव देता है कि http://xxxx/v2/user/123 जैसे किसी दिन एक उच्च एपीआई-संस्करण होगा। लेकिन यह आरईएसटी शर्तों में समझ में नहीं आता है, एपीआई संस्करण स्वयं HTTP 1.0 या 1.1 है, जो पहले ही HTTP अनुरोध के अंदर भेजा गया है। यह आरईएसटी संसाधन केंद्रित दृश्य एसओएपी या जावा-इंटरफेस जैसे अन्य एपीआई-इंटरफेस से बहुत अलग है (जहां योग्य नामों में एपीआई संस्करण होना आम है)।

आरईएसटी में एकमात्र चीज जहां संस्करण समझ में आता है वह उस संसाधन का प्रतिनिधित्व है (उदाहरण के लिए नए फ़ील्ड जोड़े या हटा दिए जाते हैं)। यह संस्करण सामग्री-वार्ता के हिस्से से संबंधित है जैसे:

http://xxx/user/123 + HTTP 'Accept' Header -> Content negotation through header
http://xxx/user/123?v=1                    -> for perma-links/hyperlinks

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

समेकित करने के लिए: आरईएसटी यूआरआई में कोई एपीआई-वर्जनिंग नहीं है, केवल संसाधन के प्रतिनिधित्व का संस्करण है। प्रतिनिधित्व संस्करण-जानकारी सामग्री-बातचीत से संबंधित है (क्वेरीपैम या HTTP 'स्वीकृति' के रूप में)।

तुम क्या सोचते हो? आप किस चीज से असहमत होंगे / सहमत होंगे?


मुझे http://xxxx/v1/user/123 भ्रमित लगता है क्योंकि यह सुझाव देता है कि http://xxxx/v2/user/123 जैसे किसी दिन एक उच्च एपीआई संस्करण होगा

यह सुझाव नहीं देता है - हालांकि भविष्य में आपकी क्षमता है।

लेकिन यह आरईएसटी शर्तों में समझ में नहीं आता है, एपीआई संस्करण स्वयं HTTP 1.0 या 1.1 है, जो पहले ही HTTP अनुरोध के अंदर भेजा गया है।

आपके एपीआई का संस्करण और HTTP के संस्करण जिसे आप अनुरोध करने के लिए उपयोग कर रहे हैं, बराबर नहीं होना चाहिए।

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

जैसा आपने प्रदर्शित किया है, यूआरआई पैरामीटर के रूप में संस्करण रखना ठीक है।

http://xxx/user/123?v=1 -> परमा-लिंक / हाइपरलिंक्स के लिए


आप X-API-Version HTTP अनुरोध हेडर के लिए सुन सकते हैं। यदि हेडर मौजूद है, तो सर्वर को एपीआई के उस संस्करण का उपयोग करना होगा। यदि हेडर मौजूद नहीं है, तो सर्वर एपीआई के नवीनतम संस्करण का उपयोग कर सकता है।

> GET /user/123 HTTP/1.1
> Host: xxx
> X-API-Version: >=1.5.1, <2.0.0
> Accept: application/json
>

< HTTP/1.1 200 OK
< X-API-Version: 1.6.12
<
< { "user": { "id": 123, "name": "Bob Smith" } }
<

इसके लायक होने के लिए, मैं आपके साथ मैनुअल से सहमत हूं। आप इस सवाल में मेरा तर्क देख सकते हैं कि संस्करण आरईएसटी यूआरआई कैसे करें

ऐसे बहुत सारे लोग हैं जो असहमत लगते हैं लेकिन मैं चिंता नहीं करता। जब तक आप हाइपरटेक्स्ट बाधा का सम्मान करते हैं, तब तक आपका यूआरएल वास्तव में आपके क्लाइंट पर बड़ा प्रभाव नहीं डालता है।


एक अन्य दृष्टिकोण यह कह सकता है कि "एक प्रतिनिधित्व में कई एपीआई हैं":

http://xxx/user/123/api/1.json

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

http://xxx/user/123.json

व्यक्तिगत रूप से मुझे अन्य समाधान बेहतर पसंद हैं लेकिन यह एक और तरीका है जिसे मैंने अभी तक सुझाया नहीं है।


मैं सहमत हूं कि आप अपने एपीआई में प्रस्तुत संसाधनों के यूआरआई में संस्करण देखना नहीं चाहते हैं। इससे उन्हें "ठंडा" नहीं होता है। यह भी सहमति है कि यह प्रतिनिधित्व है जो बदलने की संभावना है।

हालांकि यह तब होता है जब आप किसी विशेष प्रतिनिधित्व की सामग्री को बदलते हैं तो क्या होता है। उदाहरण के लिए यदि आपका मूल JSON एक फ्रोबनिट्ज़ का प्रतिनिधित्व है

{"x": "bam", "y": "hello"}

और आप एक "z" फ़ील्ड जोड़ना चाहते हैं जो आपको लगता है कि क्लाइंट को कुछ जागरूकता होनी चाहिए कि हम अब किसी प्रकार की डेटा स्कीम के संस्करण 2 पर हैं।

मैं इस बारे में निश्चित नहीं हूं। मुझे लगता है कि आपके पास कुछ विकल्प हैं:

  • चेहरे में धीरे-धीरे बदलते प्रतिनिधित्वों को अपने ग्राहकों को लचीला बनाएं। उपरोक्त उदाहरण में हम अभी भी एक JSON शब्दकोश उत्पन्न कर रहे हैं।
  • यदि आपको अवश्य ही प्रस्तुत करना है (इस उदाहरण में एक संस्करण फ़ील्ड)। ऐसा करके आप JSON सामग्री-प्रकार के भीतर प्रभावी रूप से उप-प्रतिनिधित्व घोषित कर रहे हैं। मुझे लगता है कि हालांकि यह काफी सीमित है।
  • अपने स्वयं के एमआईएमई प्रकारों का प्रयोग करें और उन्हें संस्करण: एप्लिकेशन / एक्स-माय-स्पेशल-जेसन 1.0, एप्लिकेशन / एक्स-माय-स्पेशल-जेसन 1.1। यह आपको एक दूसरे के स्वतंत्र रूप से अपने प्रतिनिधित्व संस्करण को संस्करणित करने की अनुमति देता है। दोबारा, इस के साथ आप अपने ग्राहकों को यह जानने के लिए एक महत्वपूर्ण मांग कर रहे हैं कि क्या हो रहा है।

आम तौर पर मुझे लगता है कि आप अपने एपीआई और उन ग्राहकों के लिए अपने प्रतिनिधित्व को अनुकूलित करना चाहते हैं जिन्हें आपने स्वयं का आविष्कार नहीं किया है; वे लोग जो आपके संसाधनों की खोज करने पर बनाएंगे। मेरा मानना ​​है कि यह तब भी उपयोगी होता है जब आप कुछ ऐसा कर रहे होते हैं जो निजी है क्योंकि यह एक उपयोगी डिजाइन बाधा में बनाता है जो आपके सिस्टम को और अधिक मजबूत बनाने में मदद करेगा।





api-design