आम्ही सामान्यत: मानक डेटा एक्सचेंज मेट्रिक्स वापरतो जसे की JSON किंवा XML REST वेब सेवांसह. तथापि, बर्‍याच आरईएसटी सेवांमध्ये कमीतकमी काही ऑपरेशन्स असतात जी केवळ JSON किंवा XML सह करणे कठीण असते. उदाहरणांमध्ये उत्पादन प्रतिमा अपलोड करणे, अपलोड केलेल्या CSV फायलींद्वारे डेटा आयात करणे किंवा डाउनलोड करण्यायोग्य PDF अहवाल तयार करणे समाविष्ट आहे.

या पोस्टमध्ये, आम्ही त्या क्रियांवर लक्ष केंद्रित करतो ज्यांना अनेकदा फाईल डाउनलोड և अपलोड म्हणून वर्गीकृत केले जाते. ही थोडी अडचण आहे, कारण एक साधा JSON दस्तऐवज पाठवणे देखील (JSON) फाइल अपलोड ऑपरेशन म्हणून मानले जाऊ शकते.

तुम्हाला कोणती कृती करायची आहे याचा विचार करा

क्रियेसाठी आवश्यक असलेल्या विशिष्ट फाइल आकारावर लक्ष केंद्रित करणे ही एक सामान्य चूक आहे. त्याऐवजी, आपण ज्या कृती करू इच्छितो त्याबद्दल विचार करणे आवश्यक आहे. फाइल आकार फक्त ठरवते माध्यम प्रकार: शस्त्रक्रियेसाठी वापरले जाते.

उदाहरणार्थ, समजा आम्हाला एक API डिझाइन करायचे आहे जे वापरकर्त्यांना त्यांच्या वापरकर्ता खात्यात अवतार प्रतिमा अपलोड करण्याची परवानगी देते.

विविध कारणांमुळे अवतार प्रतिमा वापरकर्ता खाते संसाधनापासून विभक्त करणे सामान्यतः चांगली कल्पना आहे.

  • अवतार प्रतिमा बदलण्याची शक्यता नाही, म्हणून ती कॅशिंगसाठी चांगली उमेदवार असू शकते. दुसरीकडे, वापरकर्ता खाते संसाधनात अशा गोष्टी असू शकतात शेवटची नोंद: वारंवार बदलणारी तारीख.
  • वापरकर्ता खात्यात लॉग इन करणारे सर्व ग्राहक अवतार प्रतिमेमध्ये स्वारस्य असू शकत नाहीत. अशा प्रकारे, बँडविड्थ राखली जाऊ शकते.
  • ग्राहकांना अनेकदा प्रतिमा स्वतंत्रपणे अपलोड करण्याचा सल्ला दिला जातो (ते वापरत असलेल्या वेब अनुप्रयोगांबद्दल विचार करा लेबल)

वापरकर्ता खाते संसाधनात प्रवेश केला जाऊ शकतो:

/users/<user-id>

आम्ही अवतार प्रतिमेचे प्रतिनिधित्व करणारे एक साधे उप-संसाधन घेऊन येऊ शकतो.

/users/<user-id>/avatar

अवतार अपलोड हे एक साधे रिप्लेसमेंट ऑपरेशन आहे जे PUT द्वारे व्यक्त केले जाऊ शकते.

PUT /users/<user-id>/avatar
Content-Type: image/jpeg

<image data>

जर वापरकर्त्याला त्याची अवतार प्रतिमा हटवायची असेल तर आम्ही DELETE सोपी कृती वापरू शकतो.

DELETE /users/<user-id>/avatar

आणि, अर्थातच, ग्राहकांना त्यांची अवतार प्रतिमा दर्शविण्याचा मार्ग आवश्यक आहे. अशा प्रकारे, आम्ही GET द्वारे डाउनलोड ऑपरेशन प्रदान करू शकतो.

GET /users/<user-id>/avatar

जे परत येते

HTTP/1.1 200 Ok
Content-Type: image/jpeg

<image data>

या साध्या उदाहरणात, आम्ही सामान्य अद्यतने, हटवणे आणि व्यवहारांसह एक नवीन उप-संसाधन वापरतो. फरक एवढाच आहे की आम्ही JSON किंवा XML ऐवजी प्रतिमा मीडिया प्रकार वापरतो.

दुसरे उदाहरण पाहू.

समजा आम्ही उत्पादन डेटा व्यवस्थापित करण्यासाठी API प्रदान करतो. आम्ही अपलोड केलेल्या CSV फाइलमधून उत्पादने आयात करून हा API वाढवू इच्छितो. फायली अपलोड करण्याबद्दल विचार करण्याऐवजी आपण अ उत्पादनांची आयात ऑपरेशन

कदाचित POST पाठवण्याचा सर्वात सोपा दृष्टिकोन हा एक स्वतंत्र संसाधन आहे.

POST /product-import
Content-Type: text/csv

<csv data>

अन्यथा, आम्ही हे असे पाहू शकतो: मोठ्या प्रमाणात उत्पादन ऑपरेशन आम्हाला दुसर्या पोस्टबद्दल कसे कळले? REST सह मोठ्या प्रमाणात ऑपरेशन, पॅच पद्धत संकलनावर मोठ्या प्रमाणात कृती व्यक्त करण्याचा एक संभाव्य मार्ग आहे. या प्रकरणात, CSV दस्तऐवज इच्छित उत्पादन पोर्टफोलिओ बदलांचे वर्णन करते.

उदाहरण:

PATCH /products
Content-Type: text/csv

action,id,name,price
create,,Cool Gadget,3.99
create,,Nice cap,9.50
delete,42,,

हे उदाहरण दोन नवीन उत्पादने तयार करते – आयडीसह उत्पादन हटवा 42:.

फाइल अपलोड प्रक्रियेत बराच वेळ लागू शकतो. म्हणून ते डिझाइन करण्याचा विचार करा: अतुल्यकालिक REST ऑपरेशन.

फायली आणि मेटाडेटा मिक्स करणे

काही प्रकरणांमध्ये फाईलमध्ये अतिरिक्त मेटाडेटा जोडणे आवश्यक असू शकते. उदाहरणार्थ, समजा आमच्याकडे एक API आहे जेथे वापरकर्ते सुट्टीचे फोटो अपलोड करू शकतात. प्रतिमेच्या वास्तविक डेटा व्यतिरिक्त, फोटोमध्ये वर्णन, ती जिथे घेतली होती इत्यादी देखील असू शकते.

येथे मी (पुन्हा) अवतार प्रतिमेसह मागील विभागात नमूद केल्याप्रमाणे समान कारणासाठी दोन स्वतंत्र कृती वापरण्याची शिफारस करतो. जरी येथील परिस्थिती थोडी वेगळी असली (डेटा थेट प्रतिमेशी संबंधित आहे), तो सहसा एक सोपा दृष्टिकोन असतो.

या प्रकरणात, आम्ही प्रथम वास्तविक प्रतिमा पाठवून फोटो संसाधन तयार करू शकतो.

POST /photos
Content-Type: image/jpeg

<image data>

प्रतिसादात आम्हाला मिळते:

HTTP/1.1 201 Created
Location: /photos/123

त्यानंतर आम्ही फोटोला अतिरिक्त मेटाडेटा जोडू शकतो.

PUT /photos/123/metadata
Content-Type: application/json

{
    "description": "Nice shot of a beach in hawaii",
    "location": "hawaii",
    "filename": "hawaii-beach.jpg"
}

अर्थात, आम्ही ते वेगळ्या स्वरूपात देखील करू शकतो, प्रतिमेला मेटाडेटा पाठवू शकतो.

JSON किंवा XML मध्ये Base64 एन्क्रिप्टेड फाइल्स घाला

फाईल कंटेंट्स և मेटाडेटा वेगळ्या फाईल्समध्ये विभाजित करणे शक्य नसल्यास, आम्ही JSON / XML दस्तऐवज वापरून फायली एम्बेड करू शकतो बेस 64 एन्क्रिप्शन. बेस 64 एन्कोडिंगसह, आम्ही बायनरी आयाम मजकूरामध्ये रूपांतरित करू शकतो, जे जेएसओएन किंवा एक्सएमएल सारख्या इतर मजकूर-आधारित स्वरूपांसह एकत्रित केले जाऊ शकते.

उदाहरणार्थ, विनंती अशी असू शकते:

POST /photos
Content-Type: application/json

{
    "width": "1280",
    "height": "920",
    "filename": "funny-cat.jpg",
    "image": "TmljZSBleGFt...cGxlIHRleHQ="
}

एकाधिक क्वेरींसह मीडिया प्रकारांचे मिश्रण

प्रतिमा և मेटाडेटा हा क्वेरी / प्रतिसादात मेटाडेटा हस्तांतरित करण्याचा आणखी एक संभाव्य मार्ग आहे बहुमुखी मीडिया प्रकार.

मल्टीमीडिया मीडिया प्रकारांना एक सीमा मापदंड आवश्यक आहे जो शरीराच्या वेगवेगळ्या भागांमध्ये परिसीमन म्हणून वापरला जातो. खालील विनंतीमध्ये शरीराचे दोन भाग असतात. पहिल्यामध्ये प्रतिमा आहे आणि दुसऱ्यामध्ये मेटाडेटा आहे.

उदाहरण:

POST /photos
Content-Type: multipart/mixed; boundary=foobar

--foobar
Content-Type: image/jpeg

<image data>
--foobar
Content-Type: application/json

{
    "width": "1280",
    "height": "920",
    "filename": "funny-cat.jpg"
}
--foobar--

दुर्दैवाने, अनेक प्रश्न / उत्तरांसह कार्य करणे अनेकदा कठीण असते. उदाहरणार्थ, प्रत्येक REST ग्राहक या प्रश्नांची निर्मिती करू शकत नाही, unit युनिट चाचण्यांमध्ये उत्तरे तपासणे कठीण आहे.