HTTP और REST में क्या अंतर है?

Question

REST और SOAP के बीच के अंतर के बारे में बहुत कुछ पढ़ने के बाद, मुझे यह आभास हुआ कि REST HTTP के लिए सिर्फ एक और शब्द है। क्या कोई समझा सकता है कि HTTP में REST किस कार्यक्षमता को जोड़ता है?

नोट : मैं REST बनाम SOAP की तुलना नहीं कर रहा हूँ।

अपडेट : आपके उत्तर के लिए धन्यवाद। अब मेरे लिए यह स्पष्ट हो गया है कि REST, HTTP का उपयोग करने के तरीके के बारे में नियमों का एक सेट है। इसलिए मैंने इन सम्मेलनों के फायदे के बारे में एक अनुवर्ती पोस्ट किया ।

नोट : मैं अब REST का अर्थ समझ लेता हूं; के रूप में एमिल इवानोव की टिप्पणी है, बाकी का मतलब HTTP जिस तरह से यह होना है का उपयोग कर। हालाँकि, मुझे यकीन नहीं है कि क्या यह अपने आप में एक शब्द के योग्य है, और मुझे निश्चित रूप से इसके चारों ओर प्रचार नहीं मिला है।

Comments

साइड नोट के रूप में, शायद 90% प्रचार जो आप इन दिनों REST के बारे में सुनते हैं, वे ऐसे लोगों से हैं जो वास्तव में REST के बारे में पूरी तस्वीर नहीं समझते हैं। दुर्भाग्य से बिक्री की चर्चा हो गई है। वास्तविक लाभों का पता लगाने के लिए आपको बहुत सी बकवास से गुजरना होगा।

— डारेल मिलर

REST के आस-पास का प्रचार शायद लोगों द्वारा SOAP से बहुत अधिक नाराज होने के कारण है। हर कोई SOAP नरक से बचने के लिए खुश है: D

— aefxx

HTTP को एक विशिष्ट गेम जैसे सॉकर के साथ और REST के साथ गेम खेलने के लिए बॉल के रूप में सोचें। कुछ कहेंगे कि फुटबॉल सबसे अच्छा खेल है, अन्य असहमत होंगे। इसके लायक यह शब्द ही क्यों है? क्योंकि सभी बॉल गेम को कॉल करने से, "बॉल गेम" का मतलब है कि यह निर्धारित करने का कोई तरीका नहीं है कि आप किस नियम-सेट का उपयोग कर रहे हैं। इस तरह, हर कोई एक ही गीत पत्र (क्षमा, मिश्रित रूपक) से पढ़ रहा है

— रॉस ड्रू

अब हमारे पास REST के साथ तुलना में एक और विकल्प ग्राफकलाइन है। दोनों HTTP का उपयोग कर रहे हैं।

— हांगबो मियाओ

@RossDrew महान सादृश्य .. यह समझने में अधिक आसान बनाता है।

— अनूप

Answer 1

नहीं, REST वह तरीका है जिससे HTTP का उपयोग किया जाना चाहिए ।

आज हम केवल HTTP प्रोटोकॉल के छोटे-छोटे तरीकों का उपयोग करते हैं - अर्थात् GETऔर POST। इसे करने का REST तरीका प्रोटोकॉल के सभी तरीकों का उपयोग करना है।

उदाहरण के लिए, REST DELETEएक URI के पीछे एक डॉक्यूमेंट को मिटाने (यह एक फाइल, स्टेट इत्यादि हो सकता है) के उपयोग को निर्धारित करता है , जबकि, HTTP के साथ, आप किसी क्वेरी GETया POSTजैसे का दुरुपयोग करेंगे ...product/?delete_id=22।

Comments

और उन अन्य तरीकों का उपयोग करने से बड़ा फायदा क्या होगा?

— दिमित्री सी।

मैंने एक वास्तविक दुनिया उदाहरण के लिए एक लिंक पोस्ट किया है जो आपको फायदे दिखाएगा। चीयर्स।

— aefxx

-1 आराम करने के लिए गलत परिभाषा देने के लिए। बाकी एक प्रकार की वास्तुकला है, न कि वेब के माध्यम से संदेश भेजने का। अधिक जानकारी के लिए: en.wikipedia.org/wiki/Representational_state_transfer

— युवल पेरेलमैन

फिर से गलत। REST http / 1.0 प्रोटोकॉल के पीछे वास्तु सिद्धांत नहीं है। रैस्टफुल आर्किटेक्चर का आविष्कार बहुत बाद में हुआ। Http प्रोटोकॉल द्वारा दी गई कार्यक्षमता REST आर्किटेक्चर पर निर्भर करती है, लेकिन 2 एक दूसरे पर निर्भर नहीं हैं। यह पहिया को फिर से मजबूत करने का सवाल नहीं है, इन अवधारणाओं को समझने का सवाल है

— युवल पेरेलमैन

@aefxx धन्यवाद, मुझे यह नहीं पता था, और कभी भी पूर्ण शोध प्रबंध नहीं पढ़ा। अगर यह लॉक नहीं होता तो मैं वोटडाउन को वोटअप में बदल देता। आपके पास बहस करने का एक दिलचस्प तरीका है, आप मुझे केवल एक लिंक दे सकते हैं और उसी के साथ किया जा सकता है। shish।

— युवल पेरेलमैन

Answer 2

HTTP एक प्रोटोकॉल है जिसका उपयोग संचार के लिए किया जाता है, आमतौर पर इंटरनेट संसाधनों या किसी वेब ब्राउज़र क्लाइंट के साथ किसी भी एप्लिकेशन से संवाद करने के लिए उपयोग किया जाता है।

REST का अर्थ है कि एप्लिकेशन को डिज़ाइन करते समय आप जिस मुख्य अवधारणा का उपयोग कर रहे हैं वह संसाधन है: प्रत्येक क्रिया के लिए आप जो कार्य करना चाहते हैं, वह एक ऐसे संसाधन को परिभाषित करने की आवश्यकता है, जिस पर आप आमतौर पर केवल CRUD ऑपरेशन करते हैं, जो एक सरल कार्य है। इसके लिए 4 CRUD ऑपरेशन (Get Read, POST CREATE के लिए, PUT UPDATE के लिए है और DELETE DELETE के लिए है) के विरुद्ध HTTP प्रोटोकॉल में उपयोग की जाने वाली 4 क्रियाओं के लिए बहुत सुविधाजनक है। यह RPC की पुरानी अवधारणा (दूरस्थ प्रक्रिया कॉल) के विपरीत है, जिसमें आपके पास उन कार्यों का एक समूह है जिन्हें आप उपयोगकर्ता की कॉल के परिणामस्वरूप प्रदर्शन करना चाहते हैं। यदि आप उदाहरण के लिए सोचते हैं कि किसी पोस्ट की तरह facebook का वर्णन कैसे करें, तो RPC के साथ आप AddLikeToPost और RemoveLikeFromPost नामक सेवाएँ बना सकते हैं, और इसे FB पोस्ट से संबंधित आपकी अन्य सभी सेवाओं के साथ प्रबंधित कर सकते हैं, इस प्रकार आपको विशेष बनाने की आवश्यकता नहीं होगी पसंद के लिए वस्तु। REST के साथ आपके पास एक लाइक ऑब्जेक्ट होगा जिसे डिलीट और क्रिएट फ़ंक्शन के साथ अलग से प्रबंधित किया जाएगा। इसका मतलब यह भी है कि यह आपके db में एक अलग इकाई का वर्णन करेगा। यह एक छोटे से अंतर की तरह लग सकता है, लेकिन इस तरह से काम करना आमतौर पर बहुत सरल कोड और बहुत सरल अनुप्रयोग प्राप्त होगा। उस डिज़ाइन के साथ, आरपीसी के विपरीत, ऑब्जेक्ट की संरचना (मॉडल) से ऐप के अधिकांश तर्क स्पष्ट हैं, जिसके साथ आपको आमतौर पर स्पष्ट रूप से बहुत अधिक तर्क जोड़ना होगा।

रेस्टफुल एप्लिकेशन को डिजाइन करना आमतौर पर बहुत कठिन होता है क्योंकि इसके लिए आपको सरल तरीके से जटिल चीजों का वर्णन करना पड़ता है। केवल CRUD फ़ंक्शन का उपयोग करके सभी कार्यात्मकताओं का वर्णन करना मुश्किल है, लेकिन ऐसा करने के बाद आपका जीवन बहुत सरल हो जाएगा और आप पाएंगे कि आप बहुत छोटे तरीके लिखेंगे।

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

बेशक इसमें और भी बहुत कुछ है, लेकिन मेरी राय में एक चम्मच में यह मुख्य अवधारणा है।

Answer 3

HTTP एक एप्लिकेशन प्रोटोकॉल है। REST नियमों का एक सेट है, जिसका अनुसरण करने पर, आप वितरित अनुप्रयोग बनाने के लिए सक्षम होते हैं, जिसमें वांछित बाधाओं का एक विशिष्ट सेट होता है।

यदि आप REST के सबसे महत्वपूर्ण अवरोधों की तलाश कर रहे हैं जो कि किसी HTTP अनुप्रयोग से एक RESTful अनुप्रयोग को अलग करते हैं, तो मैं कहूंगा कि "स्व-विवरण" बाधा और हाइपरमीडिया बाधा (उर्फ हाइपरमेडिया ऑफ़ एप्लीकेशन स्टेट (HATEOAS)) के इंजन के रूप में हैं। सबसे महत्वपूर्ण।

स्व-विवरण बाधा उपयोगकर्ताओं के इरादे में पूरी तरह से आत्म वर्णनात्मक होने के लिए एक कठोर अनुरोध की आवश्यकता है। यह मध्यस्थों (परदे के पीछे और कैश) को संदेश पर सुरक्षित रूप से कार्य करने की अनुमति देता है।

HATEOAS बाधा आपके एप्लिकेशन को लिंक की एक वेब में बदलने के बारे में है जहां क्लाइंट की वर्तमान स्थिति उस वेब में उसके स्थान पर आधारित है। यह एक मुश्किल अवधारणा है और मुझे अभी समझने की तुलना में अधिक समय की आवश्यकता है।

Answer 4

जैसा कि मैं इसे समझता हूं, REST उपलब्ध HTTP आदेशों के उपयोग को लागू करता है क्योंकि वे उपयोग करने के लिए थे।

उदाहरण के लिए, मैं कर सकता था:

GET
http://example.com?method=delete&item=xxx

लेकिन बाकी के साथ मैं "DELETE" अनुरोध विधि का उपयोग करूंगा, जिससे "पद्धति" क्वेरी परम की आवश्यकता को दूर किया जा सके

DELETE
http://example.com?item=xxx

Answer 5

काफी नहीं...

http://en.wikipedia.org/wiki/Representational_State_Transfer

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

http://www.looselycoupled.com/glossary/SOAP

(सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल) वेब सेवाओं के संदेशों के लिए मानक। XML के आधार पर, SOAP एक लिफाफे प्रारूप और इसकी सामग्री का वर्णन करने के लिए विभिन्न नियमों को परिभाषित करता है। वेब सेवाओं के तीन नींव मानकों में से एक के रूप में देखा (WSDL और UDDI के साथ), यह वेब सेवाओं के आदान-प्रदान के लिए पसंदीदा प्रोटोकॉल है, लेकिन किसी भी तरह से केवल एक ही नहीं है; REST के समर्थकों का कहना है कि यह अनावश्यक जटिलता जोड़ता है।

Comments

SOAP के बारे में कुछ भी किसने कहा?

— डारेल मिलर

सवाल पूछने वाले ने .... "रेस्ट और एसओएपी के बीच के अंतर के बारे में बहुत कुछ पढ़ने के बाद"

— लियाम

Answer 6

REST बड़ी प्रणालियों (जैसे वेब) के डिजाइन के करीब पहुंचने का एक विशिष्ट तरीका है।

यह 'नियमों' (या 'बाधाओं') का एक सेट है।

HTTP एक प्रोटोकॉल है जो उन नियमों को मानने की कोशिश करता है।

Comments

मैं कहूंगा कि यदि आप HTTP का उपयोग अपनी REST सेवा के लिए परिवहन के रूप में करते हैं तो उन नियमों को मानना ​​आसान है।

— abatishchev

Answer 7

REST = प्रतिनिधि राज्य अंतरण

REST नियमों का एक सेट है, जिसका अनुसरण करने पर, आप वितरित अनुप्रयोग बनाने के लिए सक्षम होते हैं, जिसमें वांछित बाधाओं का एक विशिष्ट सेट होता है।

REST एक प्रोटोकॉल (XML, JSON आदि) संदेशों का आदान-प्रदान करने के लिए एक प्रोटोकॉल है जो उन संदेशों को लाने के लिए HTTP का उपयोग कर सकता है।

विशेषताएं:

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

स्टेटलेसनेस के लाभ:

1. वेब सेवा प्रत्येक विधि कॉल का अलग से इलाज कर सकती है।
2. वेब सेवाओं को क्लाइंट के पिछले इंटरैक्शन को बनाए रखने की आवश्यकता नहीं है।
3. यह बदले में आवेदन डिजाइन को सरल करता है।
4. HTTP अपने आप में TCP के विपरीत एक स्टेटलेस प्रोटोकॉल है और इस प्रकार Restful Web Services HTTP प्रोटोकॉल के साथ मूल रूप से काम करती है।

स्टेटलेसनेस के नुकसान:

1. हेडिंग के रूप में एक अतिरिक्त परत को ग्राहक की स्थिति को संरक्षित करने के लिए हर अनुरोध में जोड़ा जाना चाहिए।
2. सुरक्षा के लिए हमें हर अनुरोध में एक हेडर जानकारी जोड़ने की आवश्यकता है।

HTTP तरीके REST द्वारा समर्थित:

प्राप्त करें: / स्ट्रिंग / someotherstring यह एक आदर्श है और आदर्श रूप से हर बार कॉल किए जाने पर उसी परिणाम को वापस करना चाहिए

PUT: GET की तरह ही। Idempotent और संसाधनों को अद्यतन करने के लिए उपयोग किया जाता है।

POST: संसाधन बनाने के लिए उपयोग किया जाने वाला url और निकाय होना चाहिए। एकाधिक कॉलों को आदर्श रूप से अलग-अलग परिणाम लौटाने चाहिए और कई उत्पाद बनाने चाहिए।

DELETE: सर्वर पर संसाधनों को हटाने के लिए उपयोग किया जाता है।

सिर:

HEAD विधि GET के समान है सिवाय इसके कि सर्वर प्रतिक्रिया में संदेश-निकाय नहीं लौटाए। एक हेड अनुरोध के जवाब में HTTP हेडर में सम्‍मिलित मेटा जानकारी जीईटी अनुरोध के जवाब में भेजी गई सूचना के समान होगी।

विकल्प:

यह विधि क्लाइंट को किसी संसाधन कार्रवाई से संबंधित या संसाधन पुनर्प्राप्ति को लागू किए बिना किसी संसाधन से जुड़े विकल्पों और / या आवश्यकताओं को निर्धारित करने की अनुमति देती है।

HTTP प्रतिक्रियाएँ

सभी प्रतिक्रियाओं के लिए यहां जाएं ।

यहाँ कुछ महत्वपूर्ण हैं: 200 - ठीक 3XX - ग्राहक से अतिरिक्त जानकारी की आवश्यकता है और url पुनर्निर्देशन 400 - खराब अनुरोध
401 -
403 तक पहुंचने के लिए अनधिकृत - निषिद्ध
अनुरोध मान्य था, लेकिन सर्वर कार्रवाई से इनकार कर रहा है। उपयोगकर्ता के पास संसाधन के लिए आवश्यक अनुमति नहीं हो सकती है, या उसे किसी प्रकार के खाते की आवश्यकता हो सकती है।

404 - नहीं मिला
अनुरोधित संसाधन नहीं मिला लेकिन भविष्य में उपलब्ध हो सकता है। ग्राहक द्वारा अनुवर्ती अनुरोध अनुमेय हैं।

405 - विधि अनुमति नहीं है अनुरोधित संसाधन के लिए अनुरोध विधि समर्थित नहीं है; उदाहरण के लिए, एक फॉर्म पर एक GET अनुरोध जिसे POST के माध्यम से प्रस्तुत किया जाना चाहिए, या केवल-पढ़ने के लिए संसाधन पर एक PUT अनुरोध।

404 - अनुरोध
500 नहीं मिला - आंतरिक सर्वर विफलता
502 - खराब गेटवे त्रुटि

Answer 8

HTTP एक संचार प्रोटोकॉल है जो एक नेटवर्क पर संदेशों को स्थानांतरित करता है। SOAP XML- आधारित संदेशों का आदान-प्रदान करने वाला एक प्रोटोकॉल है, जो उन संदेशों को लाने के लिए HTTP का उपयोग कर सकता है। बाकी किसी भी (XML या JSON) संदेशों का आदान-प्रदान करने के लिए एक प्रोटोकॉल है जो उन संदेशों को परिवहन करने के लिए HTTP का उपयोग कर सकता है।

Comments

आपका जवाब सवाल का जवाब नहीं देता है।

— अनीस

आपकी HTTP और SOAP परिभाषा बहुत अच्छी थी और मेरे लिए प्रश्न को मंजूरी दे दी। लेकिन मैं नहीं मानता कि रेस्ट एक प्रोटोकॉल है। यह एक आर्किटेक्चरल गाइडलाइन है जो HTTP ट्रांसपोर्ट प्रोटोकॉल के सही उपयोग को लागू करता है।

— CapturedTree

Answer 9

HTTP is a contract, a communication protocol and REST is a concept, an architectural style जो HTTP, FTP या अन्य संचार प्रोटोकॉल का उपयोग कर सकता है लेकिन HTTP के साथ व्यापक रूप से उपयोग किया जाता है।

REST implies a series of constraints about how Server and Client should interact। HTTP is a communication protocol with a given mechanism for server-client data transfer, यह आमतौर पर REST API में सबसे अधिक उपयोग किया जाता है क्योंकि REST was inspired by WWW (world wide web) which largely used HTTPREST परिभाषित होने से पहले, इसलिए HTTP के साथ REST API शैली को लागू करना आसान है।

There are three major constraints in REST (but there are more):

1. सर्वर और क्लाइंट के बीच बातचीत को केवल हाइपरटेक्स्ट के माध्यम से वर्णित किया जाना चाहिए।

2.सर्वर और क्लाइंट को शिथिल रूप से जोड़ा जाना चाहिए और एक दूसरे के बारे में कोई धारणा नहीं बनानी चाहिए। क्लाइंट को केवल संसाधन प्रविष्टि बिंदु पता होना चाहिए। प्रतिक्रिया में सर्वर द्वारा इंटरैक्शन डेटा प्रदान किया जाना चाहिए।

3.सर्वर को अनुरोध संदर्भ के बारे में कोई जानकारी संग्रहीत नहीं करनी चाहिए। अनुरोध स्वतंत्र और सुस्पष्ट होना चाहिए (यदि एक ही अनुरोध को बार-बार दोहराया जाता है, ठीक उसी परिणाम को पुनः प्राप्त किया जाता है)

और HTTP सिर्फ एक संचार प्रोटोकॉल (एक उपकरण) है जो इसे प्राप्त करने में मदद कर सकता है।

अधिक जानकारी के लिए इन लिंक की जाँच करें:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Answer 10

आराम जरूरी से बंधी नहीं है HTTP । रैस्टफुल वेब सेवाएँ केवल वेब सेवाएँ हैं जो रैस्टफुल आर्किटेक्चर का अनुसरण करती हैं।

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Comments

HTTP है 1-Client-server, 2-stateless, 3-casheable। फिर HTTP पर REST में कौन सी अतिरिक्त सुविधाएँ / बाधाएँ हैं? हम REST के साथ क्या कर सकते हैं जो अकेले HTTP के साथ नहीं किया जा सकता है?

— वाफिक

Answer 11

से आप HTTP और REST के बीच अंतर नहीं जानते हैं

तो REST आर्किटेक्चर और HTTP 1.1 प्रोटोकॉल एक दूसरे से स्वतंत्र हैं, लेकिन HTTP 1.1 प्रोटोकॉल को REST के सिद्धांतों और बाधाओं का पालन करने के लिए आदर्श प्रोटोकॉल बनाया गया था। HTTP और REST के बीच के संबंध को देखने का एक तरीका यह है कि REST डिज़ाइन है, और HTTP 1.1 उस डिज़ाइन का कार्यान्वयन है।

Answer 12

बाकी एपीआई हाइपरटेक्स्ट-चालित होने चाहिए

से रॉय फील्डिंग के ब्लॉग यहाँ तरीकों से आप एक HTTP एपीआई या एक REST API का निर्माण कर रहे हैं, तो जाँच करने के लिए का एक सेट है:

API डिज़ाइनर, अपनी रचना को REST API कहने से पहले कृपया निम्नलिखित नियमों पर ध्यान दें:

• REST API किसी एकल संचार प्रोटोकॉल पर निर्भर नहीं होना चाहिए, हालाँकि किसी दिए गए प्रोटोकॉल के लिए इसकी सफल मैपिंग मेटाडेटा की उपलब्धता, विधियों की पसंद आदि पर निर्भर हो सकती है। सामान्य तौर पर, पहचान के लिए URI का उपयोग करने वाले किसी भी प्रोटोकॉल तत्व को अनुमति देनी चाहिए। उस पहचान के लिए किसी भी यूआरआई योजना का उपयोग किया जाएगा। [यहाँ असफलता का तात्पर्य है कि पहचान बातचीत से अलग नहीं होती है।]
• REST API में किसी भी तरह के HTTP प्रोटोकॉल या लिंक हेडर फ़ील्ड जैसे मानक प्रोटोकॉल के अंडरस्क्राइब्ड बिट्स के विवरण को भरने या अलग करने से संचार प्रोटोकॉल में कोई बदलाव नहीं होना चाहिए। टूटे हुए कार्यान्वयन के लिए वर्कअराउंड (जैसे कि उन ब्राउज़रों को यह विश्वास करने के लिए पर्याप्त मूर्खता है कि HTML HTTP की विधि सेट को परिभाषित करता है) को अलग से, या कम से कम परिशिष्टों में परिभाषित किया जाना चाहिए, इस उम्मीद के साथ कि वर्कअराउंड अंततः अप्रचलित हो जाएगा। [यहाँ असफलता का तात्पर्य है कि संसाधन इंटरफेस वस्तु-विशिष्ट हैं, सामान्य नहीं।]
• REST API को अपने सभी वर्णनात्मक प्रयासों को संसाधनों और ड्राइविंग एप्लिकेशन स्थिति का प्रतिनिधित्व करने के लिए उपयोग किए जाने वाले मीडिया प्रकार (ओं) को परिभाषित करने में, या मौजूदा मानक मीडिया प्रकारों के लिए विस्तारित संबंध नामों और / या हाइपरटेक्स्ट-सक्षम मार्क-अप को परिभाषित करने में खर्च करना चाहिए। किसी भी प्रकार के यूआरआई को एक मीडिया प्रकार (और, ज्यादातर मामलों में, पहले से मौजूद मीडिया प्रकारों द्वारा परिभाषित) के नियमों के दायरे में पूरी तरह से परिभाषित किया जाना चाहिए, इस पर उपयोग करने के तरीकों का वर्णन करने में खर्च किया गया कोई भी प्रयास। [यहाँ असफलता का अर्थ है कि बाहर की जानकारी हाइपरटेक्स्ट के बजाय बातचीत चला रही है।]
• REST API को निश्चित संसाधन नाम या पदानुक्रम (क्लाइंट और सर्वर का स्पष्ट युग्मन) को परिभाषित नहीं करना चाहिए। नौकरों को अपने स्वयं के नामस्थान को नियंत्रित करने की स्वतंत्रता होनी चाहिए। इसके बजाय, सर्वरों को क्लाइंट को यह निर्देश देने की अनुमति देता है कि मीडिया के प्रकार और लिंक संबंधों के भीतर उन निर्देशों को परिभाषित करके, उपयुक्त यूआरआई का निर्माण कैसे करें, जैसे कि HTML फॉर्म और यूआरआई टेम्प्लेट में किया जाता है। [यहाँ असफलता का तात्पर्य है कि क्लाइंट्स एक डोमेन-विशिष्ट मानक, जो कि RPC के कार्यात्मक युग्मन के बराबर डेटा-उन्मुख है) जैसे बैंड की जानकारी के कारण एक संसाधन संरचना मान रहे हैं।
• REST API में "टाइप" संसाधन नहीं होने चाहिए जो क्लाइंट के लिए महत्वपूर्ण हों। विनिर्देश लेखक इंटरफ़ेस के पीछे सर्वर कार्यान्वयन का वर्णन करने के लिए संसाधन प्रकारों का उपयोग कर सकते हैं, लेकिन उन प्रकारों को ग्राहक के लिए अप्रासंगिक और अदृश्य होना चाहिए। क्लाइंट के लिए महत्वपूर्ण एकमात्र प्रकार वर्तमान प्रतिनिधित्व के मीडिया प्रकार और मानकीकृत संबंध नाम हैं। [डिट्टो]
• REST API को प्रारंभिक URI (बुकमार्क) से परे कोई पूर्व ज्ञान के साथ दर्ज किया जाना चाहिए और मानकीकृत मीडिया प्रकारों का सेट जो कि इच्छित श्रोताओं के लिए उपयुक्त हो (अर्थात, किसी भी क्लाइंट द्वारा समझा जा सकता है जो एपीआई का उपयोग कर सकता है)। उस बिंदु से, सभी एप्लिकेशन स्टेट ट्रांज़िशन को क्लाइंट-प्रदान किए गए विकल्पों के क्लाइंट चयन द्वारा संचालित किया जाना चाहिए जो प्राप्त अभ्यावेदन में मौजूद हैं या उन अभ्यावेदन के उपयोगकर्ता के हेरफेर से निहित है। संक्रमण मीडिया प्रकारों और संसाधन संचार तंत्र के ग्राहक के ज्ञान को निर्धारित (या सीमित) करके किया जा सकता है, इन दोनों को ऑन-द-फ्लाई (जैसे, कोड-ऑन-डिमांड) में सुधार किया जा सकता है। [यहां असफलता का अर्थ है कि बाहर की जानकारी हाइपरटेक्स्ट के बजाय बातचीत चला रही है।]