प्रत्येक वेब एप्लिकेशन - प्रत्येक वेबसाइट - एक सेवा है। (...) ऐसी विशेषताएं जो वेब सर्फर का उपयोग करने के लिए वेब साइट को आसान बनाती हैं, वे भी प्रोग्रामर के लिए एक वेब सेवा एपीआई आसान बनाती हैं।क्या वेबसाइट भी वेब संसाधन होनी चाहिए?
रिचर्डसन और रूबी, "RESTful वेब सेवाओं"
मैं इसे इरादा के रूप में, एक वेब साइट है कि यह भी एक वेब सेवा अपने संसाधनों का अधिक प्रतिनिधित्व प्रदान करता है, क्या उपयोगकर्ता के एजेंट के आधार पर अनुरोध। एपीआई, बोलने के लिए, वेब साइट ही है, और अलग से प्रदान नहीं की जाती है।
जंगली में कई लोकप्रिय "आरईएसटी एपीआई" के लिए यह मामला नहीं है। उदाहरण के लिए, ट्विटर का एपीआई http://api.twitter.com/1/ पर स्थित है, यूआरआई में '1' एपीआई का संस्करण है। सोशलकास्ट https://demo.socialcast.com/api/ पर एक आरईएसटी एपीआई भी प्रदान करता है, तीसरा स्तर का नाम उस नेटवर्क का नाम है जो इसे संबोधित करता है।
यह मेरे लिए गलत लगता है। अगर मेरे पास http://www.example.com/blog पर मेरा ब्लॉग है, तो मुझे केवल एक अलग स्थान पर एपीआई प्रदान करने की आवश्यकता नहीं है, केवल रोबोट के लिए JSON की सेवा करना। http://www.example.com/blog/posts/ और http://api.example.com/blog/posts, दो अलग-अलग यूआरआई होने के बजाय, मेरे पास केवल पूर्व, और एकाधिक प्रस्तुतियां उपलब्ध होनी चाहिए, जिनमें से JS12 API के लिए application/json है, जो मैं अपने उपयोगकर्ताओं को प्रदान करना चाहता हूं।
उदाहरण 1: एक ब्राउज़र अपने ब्लॉग पर पोस्ट के लिए पूछ रहा;
अनुरोध:
curl -i \
-H "Accept: text/html" \
-X GET \
http://www.example.org/blog/posts/
प्रतिक्रिया:
200 OK
Content-Type: text/html; charset=utf-8
<html><body><h1>Posts</h1><ol><li><h2>My first post ...
उदाहरण 2: उसी URI, लेकिन इस बार एक रोबोट अनुरोध करता है;
अनुरोध:
curl -i \
-H "Accept: application/json" \
-X GET \
http://www.example.org/blog/posts/
प्रतिक्रिया: एपीआई के लिए
200 OK
Content-Type: text/html; charset=utf-8
{
"posts": [
{
"id": 1,
"title": "My first post" ...
संस्करण संख्या अनुरोध हेडर की "स्वीकार" क्षेत्र में एन्कोड किया जाना चाहिए, और से बचने के सब से ऊपर दृढ़ता से टाइपिंग ट्विटर जैसे यूआरआई ("स्थिति/show.json? id = 210462857140252672" या "स्थिति/शो/210462857140252672.json") करते हैं।
मैं एकीकृत दृष्टिकोण के लिए जाकर कुछ लचीलापन खो सकता हूं (लेकिन, Cool URIs never change? नहीं होना चाहिए), लेकिन मुझे लगता है कि आरईएसटी (या कम से कम मेरी व्याख्या) का पालन करने से अधिक लाभ मिलेगा।
कौन सा सही दृष्टिकोण है: एपीआई और वेबसाइट को अलग करना, या उन्हें एकीकृत करना?
कस्टम हेडर क्यों? यही है कि 'स्वीकार करें' शीर्षलेख है। –
@fab फिक्स्ड। आप सही हैं;) –