HTTP API अवलोकन

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

बुनियादी बातें

बेस पथ। हर ऑपरेशन /api/v1 के अंतर्गत है, उदाहरण के लिए https://arkvory.example/api/v1/repositories। एकमात्र अपवाद /health के अंतर्गत हेल्थ चेक हैं।
फ़ॉर्मैट। अनुरोध और उत्तर JSON (application/json) हैं। JSON बॉडी 64 KiB तक सीमित है, और JSON ऑपरेशन के लिए कोई दूसरा कंटेंट प्रकार भेजने वाले अनुरोध को 415 मिलता है। फ़ाइलों के बाइट application/octet-stream के रूप में भेजे जाते हैं।
अज्ञात फ़ील्ड। ज़्यादातर ऑपरेशन ऐसे अनुरोध को अस्वीकार करते हैं जिसमें कोई ऐसा फ़ील्ड हो जिसे वे परिभाषित नहीं करते (400, फ़ील्ड details में)। उत्तरों में, जिन फ़ील्ड को आप नहीं जानते उन्हें अनदेखा करें।
समय UTC में RFC 3339 टाइमस्टैम्प हैं। आर्टिफ़ैक्ट, अपलोड, जॉब, खातों और कुंजियों की ID UUID हैं।
नाम। रिपॉज़िटरी का नाम [a-z0-9][a-z0-9_-]{0,63} से मेल खाता है। फ़ाइल नाम (आर्टिफ़ैक्ट नाम) में 240 अक्षर तक होते हैं और कोई / या \ नहीं। रिपॉज़िटरी में पथ में 1,024 अक्षर तक होते हैं।
कैशिंग। उत्तरों के साथ Cache-Control: private, no-store होता है।
अन्य प्रोटोकॉल। मार्ग /v2 (कंटेनर), /lfs (Git LFS) और /npm अपने-अपने क्लाइंट के विनिर्देशों का पालन करते हैं और अपने स्वयं के त्रुटि प्रारूप इस्तेमाल करते हैं। वे OpenAPI दस्तावेज़ का हिस्सा नहीं हैं। क्लाइंट और प्रोटोकॉल देखें।

आकार और गिनती

एक JSON संख्या हर 64-बिट मान नहीं रख सकती। इसलिए Arkvory आकार और बाइट काउंटर दशमलव स्ट्रिंग के रूप में भेजता है: "size": "1048576"। यही बात उस आकार पर भी लागू होती है जिसे आप अपलोड बनाते समय घोषित करते हैं। आकार में कोई चिह्न नहीं, कोई अग्रणी शून्य नहीं और 16 से अधिक अंक नहीं होते। काउंट, संशोधन, सीमाएँ और भाग इंडेक्स सामान्य JSON पूर्णांक हैं।

सबसे बड़ा ऑब्जेक्ट 10,000 GiB (10 737 418 240 000 बाइट) है, जब तक कि व्यवस्थापक कोई कम ARKVORY_MAX_OBJECT_BYTES सेट न करे। इससे बड़ा घोषित आकार 400 के साथ अस्वीकार कर दिया जाता है।

प्रमाणीकरण

साइन-इन, सार्वजनिक हेल्थ चेक और साइन-इन विकल्पों को छोड़कर हर ऑपरेशन के लिए हेडर Authorization: Bearer <credential> में क्रेडेंशियल चाहिए। क्रेडेंशियल कंसोल सत्र, व्यक्तिगत एक्सेस टोकन, सेवा कुंजी या पुनर्प्राप्ति कुंजी होता है। क्रेडेंशियल क्या कर सकता है, यह उसके प्रकार और हर ऑपरेशन के एक्सेस नियम पर निर्भर करता है। इंटीग्रेशन डिज़ाइन करने से पहले प्रमाणीकरण पढ़ें, और ऑटोमेशन को केवल उन्हीं कार्रवाइयों वाली सेवा कुंजी दें जिनकी उसे ज़रूरत है।

डिस्कवरी

क्लाइंट अनुमान लगाने के बजाय सर्वर से पूछ सकता है कि वह क्या समर्थन करता है। इन सभी के लिए क्रेडेंशियल चाहिए।

अनुरोध	उत्तर
`GET /api/v1/capabilities`	API संस्करण (`v1`), गेटवे की भूमिका (`api` या `reader`), फ़ीचर फ़्लैग और इस सर्वर की सीमाएँ: `maxObjectBytes`, `partBytes` (सबसे छोटा भाग, 8 MiB), `maxPartBytes` (1 GiB), `maxParts` (10,000) और `maxPageSize` (100)।
`GET /api/v1/operations`	वे ऑपरेशन जिन्हें यह क्रेडेंशियल शायद कॉल कर सकता है, हर एक के `operationId`, मेथड, पथ, `surface`, `retry` श्रेणी, आवश्यक कार्रवाइयों और शेष शर्तों के साथ। `repository`, `surface`, `after` और `limit` (1 से 100, डिफ़ॉल्ट रूप से 50) से फ़िल्टर करें। यह सूची सलाहकारी है: निर्णय केवल वास्तविक अनुरोध करता है।
`GET /api/v1/openapi.json`	राइटर API का OpenAPI 3.0.3 दस्तावेज़। केवल एक surface पाने के लिए `?surface=<name>` जोड़ें।
`GET /api/v1/auth/permissions`	कॉल करने वाले क्रेडेंशियल की प्रति-रिपॉज़िटरी कार्रवाइयाँ।
`GET /api/v1/auth/me`	क्रेडेंशियल कौन है, उसका प्रकार और उसके मोटे `read`/`write` अनुदान।
`GET /api/v1/repositories`	वे रिपॉज़िटरी जो क्रेडेंशियल देख सकता है।

सीमाओं को हार्ड-कोड करने के बजाय उन्हें पढ़ने के लिए capabilities इस्तेमाल करें। जिस फ़ीचर फ़्लैग को आप नहीं जानते उसे false मानें।

Surfaces

ऑपरेशन छह surface में समूहित हैं। वे कॉन्ट्रैक्ट के लेबल हैं, अलग सेवाएँ नहीं; URL नहीं बदलते।

Surface	इसमें क्या शामिल है
`discovery`	क्षमताएँ, ऑपरेशन कैटलॉग, OpenAPI और रिपॉज़िटरी
`identity`	साइन-इन, कॉलर की अपनी पहचान, टोकन और कुंजी सक्रियण
`catalog`	आर्टिफ़ैक्ट, एनोटेशन, पैकेज, पथ वाली फ़ाइलें, स्टेज, प्रमोशन, अटैचमेंट
`transfers`	अपलोड सत्र, भाग, पूर्णता जॉब और डाउनलोड
`administration`	खाते, समूह, सेवा खाते, कुंजियाँ, प्रत्यायोजन, अपडेट और बैकअप
`operations`	Liveness, readiness, मेट्रिक्स और फ़ीडबैक

हेल्थ चेक बिना क्रेडेंशियल वाले GET /health/live (प्रोसेस चल रहा है) और GET /health/status (सार्वजनिक; {"status":"ready"} या unavailable) हैं, और क्रेडेंशियल वाले GET /health/ready और GET /health/metrics हैं। वे अनुरोध बजट का उपयोग नहीं करते, इसलिए लोड के कारण बैलेंसर सर्वर को हटा नहीं देता।

पेजिंग

सूची एक बार में एक पृष्ठ के रूप में लौटाई जाती है। उत्तर में items और next होते हैं। जब next null न हो, तो अगला पृष्ठ पढ़ने के लिए उसे बिना बदले क्वेरी पैरामीटर after में वापस भेजें; जब वह null हो, तो सूची पूरी है। कर्सर को अपारदर्शी स्ट्रिंग मानें और स्वयं एक न बनाएँ।

limit पृष्ठ का आकार तय करता है, 1 से 100 तक। इसे छोड़ने पर ज़्यादातर सूचियाँ 50 आइटम लौटाती हैं। पृष्ठ स्नैपशॉट नहीं हैं: पढ़ते समय आने वाले आइटम दिख भी सकते हैं और नहीं भी। next का अनुसरण करते समय फ़िल्टर और क्रम समान रहने चाहिए।

संशोधन और compare-and-swap

जिन चीज़ों को लोग संपादित करते हैं, उनका संशोधन 1 से ऊपर गिना जाता है: आर्टिफ़ैक्ट के लेबल, मेटाडेटा और संग्रह, बिल्ड के अटैचमेंट, फ़ाइल पथ, स्टोरेज नीति, बैकअप योजना और सेवा खाते की सेटिंग्स। बदलाव अनुरोध बॉडी में अपेक्षित संशोधन को expectedRevision के रूप में बताता है:

json

{ "expectedRevision": 3, "value": { "labels": ["tested"], "metadata": {}, "collections": [] } }

यदि वर्तमान संशोधन 3 नहीं है, तो कुछ नहीं बदलता और सर्वर revision_mismatch कारण के साथ 409 उत्तर देता है। यह compare-and-swap है। स्थिति फिर से पढ़ें, उस पर अपना बदलाव लागू करें और नया संशोधन भेजें। लिखने को बाध्य करने के लिए बड़ी संख्या के साथ कभी लूप न करें। किसी ऐसी चीज़ के लिए 0 इस्तेमाल करें जो अभी मौजूद नहीं है, जैसे कोई नया पथ। API If-Match हेडर का उपयोग नहीं करता।

डाउनलोड किए गए आर्टिफ़ैक्ट का सत्यापनकर्ता अलग होता है, ETag। रेंज डाउनलोड और ETag देखें।

आइडेम्पोटेंसी कुंजियाँ

Idempotency-Key हेडर दोहराए गए अनुरोध को एक बार प्रभावी बनाता है। अक्षरों, अंकों और _ . : - से बना 1 से 128 अक्षरों का मान इस्तेमाल करें, और पहले अनुरोध से पहले उसे जॉब स्थिति के साथ रखें, ताकि रीस्टार्ट हुआ जॉब वही कुंजी दोहराए। इन लेखों के लिए एक चाहिए:

ऑपरेशन	समान कुंजी और समान बॉडी के साथ दोहराव
`createUpload`	वही अपलोड सत्र लौटाता है।
`issueServiceKey` और `rotateServiceKey`	कुंजी का मेटाडेटा `200` के साथ लौटाता है, बिना सीक्रेट। यदि सीक्रेट खो गया है तो कुंजी निरस्त करें और दूसरी जारी करें।
`requestBackupRun`, `requestBackupVerify`, `requestBackupRetention`	दूसरा कतार में लगाने के बजाय वही अनुरोध लौटाता है।

अलग बॉडी के साथ वही कुंजी 409 और कारण idempotency_mismatch के साथ अस्वीकार कर दी जाती है। कुंजी कॉलर और लक्ष्य तक सीमित होती है, इसलिए दो कॉलर एक ही मान इस्तेमाल कर सकते हैं।

अन्य लेख किसी और कारण से दोहराने के लिए सुरक्षित हैं: वे स्थिति सेट करते हैं (स्टेज सेट करना, पैकेज पंजीकृत करना, कुंजी निरस्त करना), या वे compare-and-swap हैं। अगला भाग बताता है कि कौन-से।

रीट्राई नियम

हर ऑपरेशन की एक रीट्राई श्रेणी होती है। श्रेणी क्लाइंट को बताती है कि जब उसे उत्तर न मिले तो क्या करे। संदर्भ इसे हर ऑपरेशन पर "Retry" के रूप में दिखाता है।

श्रेणी	अर्थ	क्या करें
`read`	पढ़ने से कुछ नहीं बदलता।	बैकऑफ़ के साथ दोहराएँ।
`idempotent`	वही अनुरोध का वही प्रभाव होता है।	दोहराएँ। उत्तर विवरण में भिन्न हो सकता है: दो बार हटाने पर बताया जा सकता है कि ऑब्जेक्ट जा चुका है।
`idempotency-key`	केवल कुंजी के साथ सुरक्षित।	उसी `Idempotency-Key` और उसी बॉडी के साथ दोहराएँ।
`compare-and-swap`	संशोधन पर निर्भर बदलाव।	स्थिति पढ़ें, फिर से निर्णय लें, और जो संशोधन पढ़ा था उसी के साथ दोहराएँ। `409` पार करने के लिए कभी `expectedRevision` न बढ़ाएँ।
`reconcile-upload`	अपलोड सत्र का एक चरण।	पहले अपलोड और उसके भाग पढ़ें (`getUpload`, `listUploadParts`), फिर जो छूट गया है वह भेजें। पूरी-फ़ाइल वाला `PUT` बीच से जारी नहीं हो सकता: वह बाइट शून्य से फिर शुरू होता है।
`reconcile-job`	पूर्णता जॉब को कतार में लगाना।	पहले जॉब पढ़ें (`getCompletionJob`)। विफल जॉब को फिर से कतार में लगाया जा सकता है।
`never-automatic`	दोहराव कार्रवाई दो बार कर सकता है।	स्वतः दोहराएँ नहीं। परिणाम जाँचें, फिर निर्णय लें। उदाहरण: खाता, टोकन या डाउनलोड लिंक बनाना, स्टोरेज नीति चलाना, फ़ीडबैक भेजना।

नेटवर्क विफलता और स्टेटस 408, 429, 502, 503 और 504 अस्थायी हैं: श्रेणी के अनुसार दोहराएँ, कम से कम Retry-After जितनी प्रतीक्षा करें, और प्रयासों की सीमा के साथ एक्सपोनेंशियल बैकऑफ़ जोड़ें। अनुरोध बदले बिना 401, 403 और अन्य 4xx उत्तर दोहराएँ नहीं। 500 को अंधाधुंध दोहराएँ नहीं; सहायता को अनुरोध ID दें। किसी बदलाव पर 503 के बाद परिणाम अज्ञात होता है, इसलिए श्रेणी का उपयोग करके पता लगाएँ कि क्या हुआ। SDK और कमांड-लाइन क्लाइंट इन नियमों को लागू करते हैं।

रेंज डाउनलोड और ETag

…/artifacts/{id}/content के GET और HEAD मूल बाइट को "sha256:<hex>" रूप वाले मज़बूत ETag और Accept-Ranges: bytes के साथ लौटाते हैं। यही बात पैकेज द्वारा (…/packages/content) और फ़ाइल पथ द्वारा (…/asset/content, …/raw/{path}) डाउनलोड पर भी लागू होती है। वे हर अनुरोध पर वर्तमान आर्टिफ़ैक्ट खोजते हैं; packages/content और raw अपने चुने हुए को X-Arkvory-Artifact-Id में बताते हैं, ताकि आप जारी रखने के लिए उसे पिन कर सकें।

Range: bytes=0-1023, bytes=1024- और bytes=-1024 Content-Range के साथ 206 लौटाते हैं। सर्वर एक रेंज परोसता है; रेंज की सूची का उत्तर पूरी फ़ाइल से दिया जाता है।
फ़ाइल के अंत से आगे शुरुआत 416 लौटाती है, कोड invalid_input, कारण range_not_satisfiable और Content-Range: bytes */<size> के साथ।
जारी रखने के लिए, Range को If-Range: "<the ETag you saw>" के साथ भेजें। यदि किसी नाम के पीछे की सामग्री बदल गई है, तो ETag अलग होगा और आपको मिश्रित फ़ाइल के बजाय पूरी नई फ़ाइल मिलेगी।
ETag के साथ If-None-Match बिना बॉडी के 304 लौटाता है।
जो सहेजा है उसका SHA-256 जाँचें। ETag उसे साथ रखता है।

डाउनलोड लिंक (?token=) एक आर्टिफ़ैक्ट के कंटेंट मार्ग पर काम करता है। प्रमाणीकरण देखें।

त्रुटियाँ

हर विफलता का एक ही JSON लिफ़ाफ़ा होता है: code, message, requestId, और जब कहने के लिए और हो, reason, details और retryAfterSeconds। निर्णय code और reason से करें, कभी message से नहीं। अज्ञात कारण अनुपस्थित माने जाते हैं, और अज्ञात code को उसके HTTP स्टेटस से निपटाया जाता है। त्रुटियाँ देखें।

दर सीमाएँ और व्यस्त सर्वर

Arkvory प्रति मिनट API कॉल नहीं गिनता। यह सीमित करता है कि वह एक बार में कितना करता है, और यह पासवर्ड का अनुमान लगाने के प्रयासों को सीमित करता है:

व्यस्त। सर्वर एक ही समय पर निश्चित संख्या में अनुरोध और ट्रांसफ़र स्वीकार करता है (ARKVORY_MAX_REQUESTS, डिफ़ॉल्ट रूप से 128; डिफ़ॉल्ट रूप से 2 अपलोड और 16 डाउनलोड)। एक ट्रांसफ़र सीमित कतार में 20 सेकंड तक प्रतीक्षा कर सकता है। जब जगह न हो, उत्तर कोड busy के साथ 503 होता है। Retry-After के बाद दोहराएँ।
क्षमता। भरी हुई डिस्क रिज़र्व, कोटा या ऑब्जेक्ट की संख्या पर सीमा 507 लौटाती है, जो प्रतीक्षा करने से ठीक नहीं होती।
प्रयास। बहुत अधिक साइन-इन, पंजीकरण, पासवर्ड या फ़ीडबैक प्रयास कोड rate_limited के साथ 429 लौटाते हैं। प्रमाणीकरण देखें।

429 और 503 दोनों Retry-After हेडर सेकंड में ले जाते हैं (जब सर्वर के पास अनुमान न हो तो 2), और retryAfterSeconds में वही संख्या। यदि अनुरोध किसी प्रॉक्सी से जाता है, तो प्रॉक्सी अपनी सीमाएँ जोड़ सकती है।

अनुरोध ID

हर उत्तर में X-Request-Id हेडर होता है, और हर त्रुटि में requestId में वही मान होता है। इसे अपने जॉब के साथ लॉग करें और सहायता को बताएँ। आपका भेजा अनुरोध ID केवल तब इस्तेमाल होता है जब वह ARKVORY_TRUSTED_PROXIES में सूचीबद्ध प्रॉक्सी से आता है और उसमें 8 से 128 सुरक्षित अक्षर होते हैं; अन्यथा सर्वर नया बनाता है। W3C traceparent हेडर केवल सर्वर के एक्सेस लॉग में दर्ज होता है।

ब्राउज़र और CORS

Arkvory के समान पते पर मौजूद वेब पृष्ठ किसी सेटिंग के बिना काम करता है। किसी दूसरे पते पर मौजूद पृष्ठ केवल तब काम करता है जब व्यवस्थापक उसका सटीक origin ARKVORY_CORS_ORIGINS में सूचीबद्ध करे (16 तक, HTTPS या loopback HTTP)। कोई अन्य origin कुंजी के मान्य होने पर भी origin_not_allowed कारण के साथ 403 पाता है। अनुरोध कभी कुकीज़ का उपयोग नहीं करते: कुंजी Authorization हेडर में भेजें और उसे मेमोरी में रखें। एनवायरनमेंट वेरिएबल देखें।

संगतता का वादा

/api/v1 केवल जोड़ के द्वारा बदलता है: नए ऑपरेशन, नए वैकल्पिक अनुरोध फ़ील्ड, नए उत्तर फ़ील्ड, नए त्रुटि कारण और नए फ़ीचर फ़्लैग। क्लाइंट को तोड़ने वाला बदलाव, जैसे अलग अर्थ, नया अनिवार्य फ़ील्ड, अलग स्टेटस या अलग पेजिंग, API का नया संस्करण और वह अवधि पाता है जिसमें दोनों काम करते हैं। बदले में, आपके क्लाइंट को:

जिन उत्तर फ़ील्ड को वह नहीं जानता उन्हें अनदेखा करना है;
अज्ञात reason को अनुपस्थित मानना है और अज्ञात code को उसके HTTP स्टेटस से निपटाना है;
सीमाएँ capabilities से लेनी हैं;
केवल वही फ़ील्ड भेजनी हैं जिन्हें ऑपरेशन परिभाषित करता है।

operationId मान स्थिर नाम हैं। जब आप ऑपरेशन को अपने कोड से मैप करें तो उनका उपयोग करें।

उदाहरण: एक फ़ाइल अपलोड करें और उसे डाउनलोड करें

यह क्रम एक ही अनुरोध में फ़ाइल अपलोड करता है। कुछ गीगाबाइट से बड़ी फ़ाइलों के लिए, या अविश्वसनीय लिंक पर, arkvoryctl या SDK इस्तेमाल करें: वे भागों में भेजते हैं और विफलता के बाद जारी रखते हैं। उदाहरण JSON पढ़ने के लिए jq इस्तेमाल करता है।

पहले, पता और कुंजी सेट करें, और फ़ाइल का आकार और SHA-256 निकालें:

bash

export ARKVORY_URL=https://arkvory.example
export ARKVORY_KEY="$(cat ~/.arkvory/key)"
FILE=./Setup.exe
SIZE=$(stat -c %s "$FILE")
SHA=$(sha256sum "$FILE" | cut -d ' ' -f 1)

चरण 1. अपलोड आरक्षित करें। वही Idempotency-Key वही सत्र लौटाता है, इसलिए आप इस कॉल को सुरक्षित रूप से दोहरा सकते हैं।

bash

ID=$(curl -fsS -X POST "$ARKVORY_URL/api/v1/repositories/releases/uploads" \
  -H "Authorization: Bearer $ARKVORY_KEY" \
  -H "Idempotency-Key: build-1042-setup" \
  -H "Content-Type: application/json" \
  -d "{\"name\":\"Setup.exe\",\"size\":\"$SIZE\",\"sha256\":\"$SHA\",\"labels\":[\"nightly\"]}" \
  | jq -r .id)

चरण 2. बाइट भेजें। आकार और SHA-256 मेल खाने पर सर्वर आर्टिफ़ैक्ट प्रकाशित करता है।

bash

curl -fsS -X PUT "$ARKVORY_URL/api/v1/repositories/releases/uploads/$ID/content" \
  -H "Authorization: Bearer $ARKVORY_KEY" \
  -H "Content-Type: application/octet-stream" \
  -T "$FILE" | jq '{id, status}'

चरण 3. उसे डाउनलोड करें। आर्टिफ़ैक्ट ID ही अपलोड ID है।

bash

curl -fL -o Setup-copy.exe \
  -H "Authorization: Bearer $ARKVORY_KEY" \
  "$ARKVORY_URL/api/v1/repositories/releases/artifacts/$ID/content"
sha256sum Setup-copy.exe

चरण 2 {"id": "…", "status": "available"} उत्तर देता है। यदि चरण 2 के दौरान कनेक्शन टूट जाए, तो GET …/uploads/$ID से अपलोड पढ़ें: जब तक उसकी स्थिति pending है, फ़ाइल को शुरुआत से फिर भेजें। अपलोड सत्र 7 दिन रहता है। कुंजी को releases पर कार्रवाइयाँ upload.create, upload.write, upload.complete और content.read चाहिए। अपलोड और ट्रांसफ़र देखें।

संदर्भ पृष्ठ

हर पृष्ठ एक समूह के ऑपरेशन को उनके एक्सेस नियम, रीट्राई श्रेणी, पैरामीटर और उत्तरों के साथ सूचीबद्ध करता है।

सिस्टम और हेल्थ: liveness, readiness, मेट्रिक्स, OpenAPI, क्षमताएँ
रिपॉज़िटरी
अपलोड
आर्टिफ़ैक्ट और कैटलॉग
पैकेज
पथ वाली फ़ाइलें
स्टेज और प्रमोशन
स्टोरेज नीतियाँ और प्रतिधारण
मिरर
डाउनलोड लिंक
बिल्ड अटैचमेंट
खाते और साइन-इन
सेवा खाते और कुंजियाँ
बैकअप
अपडेट
फ़ीडबैक

संबंधित पृष्ठ: प्रमाणीकरण, त्रुटियाँ, TypeScript SDK।

HTTP API अवलोकन ​

बुनियादी बातें ​

आकार और गिनती ​

प्रमाणीकरण ​

डिस्कवरी ​

Surfaces ​

पेजिंग ​

संशोधन और compare-and-swap ​

आइडेम्पोटेंसी कुंजियाँ ​

रीट्राई नियम ​

रेंज डाउनलोड और ETag ​

त्रुटियाँ ​

दर सीमाएँ और व्यस्त सर्वर ​

अनुरोध ID ​

ब्राउज़र और CORS ​

संगतता का वादा ​

उदाहरण: एक फ़ाइल अपलोड करें और उसे डाउनलोड करें ​

संदर्भ पृष्ठ ​

HTTP API अवलोकन

बुनियादी बातें

आकार और गिनती

प्रमाणीकरण

डिस्कवरी

Surfaces

पेजिंग

संशोधन और compare-and-swap

आइडेम्पोटेंसी कुंजियाँ

रीट्राई नियम

रेंज डाउनलोड और ETag

त्रुटियाँ

दर सीमाएँ और व्यस्त सर्वर

अनुरोध ID

ब्राउज़र और CORS

संगतता का वादा

उदाहरण: एक फ़ाइल अपलोड करें और उसे डाउनलोड करें

संदर्भ पृष्ठ