बाहरी लिंकिंग (डीप लिंकिंग) - इंटरनेट पर, यह एक साइट पर हाइपरलिंक का स्थान है जो उस साइट के होम (होम, स्टार्ट) पेज की ओर इशारा करने के बजाय किसी अन्य वेबसाइट के पेज पर इंगित करता है। ऐसे लिंक को बाहरी लिंक (डीप लिंक) कहा जाता है।
विकिपीडिया

शब्द "डीप लिंक्स" को अंग्रेजी भाषा के "डीप लिंक्स" के सबसे निकट के रूप में उपयोग किया जाएगा। यह लेख REST API पर केंद्रित होगा, इसलिए गहरे लिंक का अर्थ HTTP संसाधनों से लिंक होगा। उदाहरण के लिए, habr.com पर एक विशिष्ट लेख के लिए गहरा लिंक habr.com/en/post/426691 अंक।

HATEOAS , REST आर्किटेक्चर का एक घटक है जो API क्लाइंट को हाइपरमीडिया के माध्यम से जानकारी प्रदान करने की अनुमति देता है। ग्राहक केवल निश्चित पते, एपीआई प्रविष्टि बिंदु को जानता है; वह सर्वर से प्राप्त संसाधनों से सभी संभावित कार्यों को सीखता है। संसाधन के विचारों में क्रियाओं या अन्य संसाधनों के लिंक होते हैं; क्लाइंट एपीआई के साथ बातचीत करता है, गतिशील रूप से उपलब्ध लिंक से एक क्रिया का चयन करता है। आप HATEOAS के बारे में विकिपीडिया पर या Habré के इस अद्भुत लेख में पढ़ सकते हैं।

HATEOAS, REST API का अगला स्तर है। हाइपरमीडिया के उपयोग के लिए धन्यवाद, वह एपीआई के विकास के दौरान उठने वाले कई सवालों के जवाब देता है: सर्वर साइड पर क्रियाओं तक पहुंच को कैसे नियंत्रित किया जाए, क्लाइंट और सर्वर के बीच तंग कनेक्टिविटी से कैसे छुटकारा पाया जाए, यदि आवश्यक हो तो संसाधनों के पते कैसे बदलें। लेकिन यह इस सवाल का जवाब नहीं देता है कि संसाधनों के गहरे लिंक कैसे दिखना चाहिए।

"क्लासिक" रीस्ट कार्यान्वयन में, क्लाइंट को पतों की संरचना पता है; वह जानता है कि रीस्ट एपीआई में पहचानकर्ता द्वारा एक संसाधन कैसे प्राप्त किया जाए। उदाहरण के लिए, एक उपयोगकर्ता ऑनलाइन स्टोर में एक पुस्तक पृष्ठ के लिए एक गहरी लिंक का अनुसरण करता है। URL बार https://domain.test/books/1 ब्राउज़र के एड्रेस बार में प्रदर्शित होता है। ग्राहक जानता है कि "1" पुस्तक के संसाधन का पहचानकर्ता है, और इसे प्राप्त करने के लिए आपको इस पहचानकर्ता को REST API URL https://api.domain.test/api/books/{id} । इस प्रकार, REST API में इस पुस्तक के संसाधन का गहरा लिंक इस तरह दिखता है: https://api.domain.test/api/books/1 ।

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

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

तो, पहला विकल्प: HATEOAS API URL हार्डकोड। ग्राहक संसाधन पते की संरचना को जानता है जिसके लिए गहरे लिंक की आवश्यकता होती है, और यह जानता है कि लुकअप के लिए संसाधन पहचानकर्ता कैसे प्राप्त करें। उदाहरण के लिए, सर्वर पुस्तक संसाधन के संदर्भ के रूप में एड्रेस https://api.domain.test/api/books/1 है। ग्राहक जानता है कि "1" पुस्तक का पहचानकर्ता है और गहरे लिंक पर क्लिक करने पर यह URL अपने आप उत्पन्न कर सकता है। यह निश्चित रूप से एक कामकाजी विकल्प है, लेकिन HATEOAS के सिद्धांतों का उल्लंघन करता है। पता संरचना और संसाधन पहचानकर्ता को अब नहीं बदला जा सकता है, अन्यथा ग्राहक टूट जाएगा, एक कठोर संबंध है। यह HATEOAS नहीं है, जिसका अर्थ है कि विकल्प हमारे अनुरूप नहीं है।

दूसरा विकल्प क्लाइंट URL में REST API URL को स्थानापन्न करना है। एक पुस्तक के साथ एक उदाहरण के लिए, गहरा लिंक इस तरह दिखाई देगा: https://domain.test/books?url=https://api.domain.test/api/books/1 । यहां, क्लाइंट सर्वर से प्राप्त संसाधन लिंक लेता है और इसे पूरी तरह से पृष्ठ पते में प्रतिस्थापित करता है। यह अधिक HATEOAS की तरह है, ग्राहक को पहचानकर्ताओं और पते की संरचना के बारे में नहीं पता है, वह एक लिंक प्राप्त करता है और इसका उपयोग करता है। इस तरह के इन-डेप्थ लिंक पर क्लिक करने पर, क्लाइंट को यूआरएल पैरामीटर से REST API लिंक के माध्यम से वांछित संसाधन प्राप्त होगा। ऐसा लगता है कि समाधान काम कर रहा है, और HATEOAS की भावना में काफी है। लेकिन यदि आप अपने बुकमार्क में ऐसा लिंक जोड़ते हैं, तो भविष्य में हम एपीआई में संसाधन का पता नहीं बदल पाएंगे (या हमें हमेशा एक नए पते पर पुनर्निर्देशित करना होगा)। एक बार फिर, HATEOAS के लाभों में से एक खो गया है, यह विकल्प भी आदर्श नहीं है।

इस प्रकार, हम चाहते हैं कि पेर्मलिंक्स हों, जो कि बदल सकती हैं। इस तरह के एक समाधान मौजूद है और इंटरनेट पर व्यापक रूप से उपयोग किया जाता है - कई साइटें आंतरिक पृष्ठों के लिए छोटे लिंक प्रदान करती हैं जिन्हें साझा किया जा सकता है। संक्षिप्तता के अलावा, उनका लाभ यह है कि साइट पृष्ठ का वास्तविक पता बदल सकती है, लेकिन ऐसे लिंक नहीं टूटेंगे। उदाहरण के लिए, Microsoft http://go.microsoft.com/fwlink/?LinkId=XXX फॉर्म के पृष्ठों की मदद के लिए विंडोज लिंक का उपयोग करता है। वर्षों से, Microsoft साइटों को कई बार फिर से डिज़ाइन किया गया है, लेकिन विंडोज के पुराने संस्करणों में लिंक काम करना जारी रखते हैं।

यह केवल HATEOAS के लिए इस समाधान को अनुकूलित करने के लिए बनी हुई है। और यह तीसरा विकल्प है - REST API में अद्वितीय गहरे लिंक आइडेंटिफ़ायर का उपयोग करना। अब पुस्तक पृष्ठ का पता इस तरह दिखेगा: https://domain.test/books?deepLinkId=3f0fd552-e564-42ed-86b6-a8e3055e2763 । इस तरह के इन-डेप्थ लिंक पर क्लिक करते समय, क्लाइंट को सर्वर से पूछना चाहिए: इस तरह के deepLinkId लिंक deepLinkId से क्या संसाधन लिंक मेल खाता है? सर्वर लिंक को वापस कर देगा https://api.domain.test/api/books/1 (अच्छी तरह से, या तुरंत एक संसाधन, ताकि दो बार जाने के लिए नहीं)। यदि REST API में संसाधन पता बदलता है, तो सर्वर बस एक और लिंक लौटाएगा। डेटाबेस में एक रिकॉर्ड सहेजा जाता है कि संदर्भ पहचानकर्ता 3f0fd552-e564-42ed-86b6-a8e3055e2763 पुस्तक 1 ​​की इकाई पहचानकर्ता से मेल खाती है।

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

उदाहरण

यह लेख एक उदाहरण के कार्यान्वयन के बिना पूरा नहीं होगा। अवधारणा का परीक्षण करने के लिए, स्प्रिंग बूट / कोटलिन पर बैकएंड के साथ काल्पनिक ऑनलाइन स्टोर कैटलॉग साइट का एक उदाहरण और Vue / जावास्क्रिप्ट पर एक एसपीए दृश्यपटल पर विचार करें। स्टोर किताबें और पेंसिल बेचता है, साइट में दो खंड हैं जिसमें आप उत्पादों की सूची देख सकते हैं और उनके पृष्ठ खोल सकते हैं।

धारा "पुस्तकें":



एक पुस्तक पृष्ठ:



माल के भंडारण के लिए, स्प्रिंग डेटा जेपीए इकाइयाँ परिभाषित की गई हैं:

 enum class EntityType { PEN, BOOK } @Entity class Pen(val color: String) { @Id @Column(columnDefinition = "uuid") val id: UUID = UUID.randomUUID() @OneToOne(cascade = [CascadeType.ALL]) val deepLink: DeepLink = DeepLink(EntityType.PEN, id) } @Entity class Book(val name: String) { @Id @Column(columnDefinition = "uuid") val id: UUID = UUID.randomUUID() @OneToOne(cascade = [CascadeType.ALL]) val deepLink: DeepLink = DeepLink(EntityType.BOOK, id) } @Entity class DeepLink( @Enumerated(EnumType.STRING) val entityType: EntityType, @Column(columnDefinition = "uuid") val entityId: UUID ) { @Id @Column(columnDefinition = "uuid") val id: UUID = UUID.randomUUID() } 

डीप लिंक DeepLink बनाने और संग्रहीत करने के लिए, DeepLink इकाई का DeepLink , DeepLink एक उदाहरण प्रत्येक डोमेन ऑब्जेक्ट के साथ बनाया जाता है। जिस समय इकाई बनाई गई थी उस समय UUID मानक के अनुसार पहचानकर्ता स्वयं उत्पन्न होता है। इसकी तालिका में गहरी कड़ी की पहचानकर्ता, पहचानकर्ता और उस इकाई का प्रकार होता है जिससे लिंक आगे बढ़ता है।

सर्वर का REST API HATEOAS अवधारणा के अनुसार आयोजित किया जाता है, API प्रविष्टि बिंदु में उत्पाद संग्रह के लिंक होते हैं, साथ ही पहचानकर्ता को प्रतिस्थापित करके गहरे लिंक बनाने के लिए #deepLink लिंक भी शामिल है:

 GET http://localhost:8080/api { "_links": { "pens": { "href": "http://localhost:8080/api/pens" }, "books": { "href": "http://localhost:8080/api/books" }, "deepLink": { "href": "http://localhost:8080/api/links/{id}", "templated": true } } } 

क्लाइंट, "पुस्तकें" अनुभाग #books समय, प्रविष्टि बिंदु पर #books लिंक पर संसाधनों के संग्रह का अनुरोध करता है:

 GET http://localhost:8080/api/books ... { "name": "Harry Potter", "deepLinkId": "4bda3c65-e5f7-4e9b-a8ec-42d16488276f", "_links": { "self": { "href": "http://localhost:8080/api/books/1272e287-07a5-4ebc-9170-2588b9cf4e20" } } }, { "name": "Cryptonomicon", "deepLinkId": "a23d92c2-0b7f-48d5-88bc-18f45df02345", "_links": { "self": { "href": "http://localhost:8080/api/books/5d04a6d0-5bbc-463e-a951-a9ff8405cc70" } } } ... 

एसपीए वी राउटर का उपयोग करता है, जिसके लिए पुस्तक पृष्ठ का { path: '/books/:deepLinkId', name: 'book', component: Book, props: true } परिभाषित किया गया है, और पुस्तक सूची के लिंक इस तरह दिखते हैं: <router-link :to="{name: 'book', params: {link: book._links.self.href, deepLinkId: book.deepLinkId}}">{{ book.name }}</router-link> ।

यही है, जब आप किसी विशिष्ट पुस्तक के पृष्ठ को खोलते हैं, तो Book घटक को कहा जाता है, जो दो मापदंडों को प्राप्त करता है: link (REST API में पुस्तक संसाधन का लिंक, #self लिंक के href क्षेत्र का मूल्य) और संसाधन से deepLinkId )।

 const Book = { template: `<div>{{ 'Book: ' + book.name }}</div>`, props: { link: null, deepLinkId: null }, data() { return { book: { name: "" } } }, mounted() { let url = this.link == null ? '/api/links/' + this.deepLinkId : this.link; fetch(url).then((response) => { return response.json().then((json) => { this.book = json }) }) } } 

Vue रूटर पृष्ठ /books/:deepLinkId के पते पर deepLinkId का मान सेट करता है, और घटक link संपत्ति से सीधे लिंक द्वारा संसाधन का अनुरोध करता है। जब पृष्ठ को रिफ्रेश करने के लिए, Vue Router घटक गुण deepLinkId सेट करता है, तो यह पृष्ठ पते से प्राप्त होता है। link संपत्ति null रहती है। घटक जांचता है: यदि संग्रह से एक सीधा लिंक प्राप्त होता है, तो उस पर संसाधन का अनुरोध किया जाता है। यदि केवल deepLinkId पहचानकर्ता deepLinkId , तो इसे डीप लिंक द्वारा संसाधन प्राप्त करने के लिए प्रवेश बिंदु से #deepLink लिंक में प्रतिस्थापित किया जाता है।

बैकएंड पर, गहरे लिंक के लिए नियंत्रक विधि इस तरह दिखती है:

 @GetMapping("/links/{id}") fun deepLink(@PathVariable id: UUID?, response: HttpServletResponse?): ResponseEntity<Any> { id!!; response!! val deepLink = deepLinkRepo.getOne(id) val path: String = when (deepLink.entityType) { EntityType.PEN -> linkTo(methodOn(MainController::class.java).getPen(deepLink.entityId)) EntityType.BOOK -> linkTo(methodOn(MainController::class.java).getBook(deepLink.entityId)) }.toUri().path response.sendRedirect(path) return ResponseEntity.notFound().build() } 

पहचानकर्ता द्वारा गहरे लिंक का सार है। एप्लिकेशन इकाई के प्रकार के आधार पर, नियंत्रक विधि के लिए एक लिंक बनाया जाता है, जो कि entityId द्वारा अपना संसाधन entityId । अनुरोध इस पते पर पुनर्निर्देशित किया गया है। इस प्रकार, अगर भविष्य में इकाई नियंत्रक के लिए लिंक बदल जाता है, तो deepLink विधि में लिंक गठन के तर्क को बदलना संभव होगा।

उदाहरण के लिए पूर्ण स्रोत कोड Github पर उपलब्ध है।