HTTP และ REST ต่างกันอย่างไร

หลังจากอ่านมากเกี่ยวกับความแตกต่างระหว่าง REST และ SOAP ฉันได้รับความประทับใจว่า REST เป็นอีกคำสำหรับ HTTP บางคนสามารถอธิบายว่า REST เพิ่มฟังก์ชันการทำงานให้กับ HTTP ได้อย่างไร

หมายเหตุ : ฉันไม่ได้มองหาการเปรียบเทียบ REST กับ SOAP

อัปเดต : ขอบคุณสำหรับคำตอบของคุณ ตอนนี้เป็นที่ชัดเจนสำหรับฉันว่า REST เป็นเพียงชุดของกฎเกี่ยวกับวิธีการใช้ HTTP ดังนั้นฉันโพสต์ติดตามเกี่ยวกับข้อดีของการประชุมเหล่านี้คืออะไร

หมายเหตุ : ตอนนี้ฉันเข้าใจความหมายของ REST แล้ว ตามที่Emil Ivanovกล่าวไว้ REST หมายถึงการใช้ HTTP อย่างที่ควรจะเป็น อย่างไรก็ตามฉันไม่แน่ใจว่าสิ่งนี้สมควรได้รับเทอมของตัวเองหรือไม่

ไม่มีส่วนที่เหลือเป็นวิธีที่HTTPควรจะนำมาใช้

วันนี้เราใช้เพียงเล็กน้อยของวิธีการของโปรโตคอล HTTP - คือและGET POSTวิธีที่เหลือทำคือใช้วิธีการทั้งหมดของโปรโตคอล

ตัวอย่างเช่น REST สั่งให้การใช้งานของDELETEการลบเอกสาร (ไม่ว่าจะเป็นไฟล์, สถานะ, ฯลฯ ) ที่อยู่ด้านหลังของ URI ในขณะที่ด้วย HTTP คุณจะใช้GETหรือPOSTแบบสอบถามแบบ...product/?delete_id=22ผิด ๆ

HTTP เป็นโปรโตคอลที่ใช้สำหรับการสื่อสารมักใช้เพื่อสื่อสารกับแหล่งข้อมูลอินเทอร์เน็ตหรือแอปพลิเคชันใด ๆ กับเว็บเบราว์เซอร์ไคลเอ็นต์

ส่วนที่เหลือหมายความว่าแนวคิดหลักที่คุณใช้ในขณะที่ออกแบบแอปพลิเคชันคือทรัพยากร: สำหรับการดำเนินการแต่ละอย่างที่คุณต้องการดำเนินการคุณต้องกำหนดทรัพยากรที่คุณมักจะดำเนินการ CRUD ซึ่งเป็นงานง่าย เพื่อให้สะดวกในการใช้คำกริยา 4 ตัวที่ใช้ในโปรโตคอล HTTP กับการดำเนินการ 4 CRUD (รับการอ่าน POST สำหรับ CREATE, PUT สำหรับ UPDATE และ DELETE สำหรับ DELETE) ซึ่งแตกต่างจากแนวคิดเก่าของ RPC (การเรียกกระบวนการระยะไกล) ซึ่งคุณมีชุดของการกระทำที่คุณต้องการดำเนินการอันเป็นผลมาจากการโทรของผู้ใช้ ถ้าคุณคิดว่าจะอธิบาย Facebook อย่างไรในโพสต์ด้วย RPC คุณอาจสร้างบริการที่ชื่อว่า AddLikeToPost และ RemoveLikeFromPost และจัดการกับบริการอื่น ๆ ที่เกี่ยวข้องกับโพสต์ FB ดังนั้นคุณไม่จำเป็นต้องสร้างพิเศษ วัตถุสำหรับไลค์ ด้วย REST คุณจะมีวัตถุ Like ซึ่งจะถูกจัดการแยกต่างหากด้วยฟังก์ชั่นลบและสร้าง นอกจากนี้ยังหมายถึงมันจะอธิบายเอนทิตีแยกต่างหากในฐานข้อมูลของคุณ ที่อาจดูเหมือนแตกต่างกันเล็กน้อย แต่การทำงานเช่นนั้นมักจะให้รหัสที่ง่ายกว่าและแอปพลิเคชันที่ง่ายกว่ามาก ด้วยการออกแบบนั้นเหตุผลส่วนใหญ่ของแอปนั้นชัดเจนจากโครงสร้างของวัตถุ (โมเดล) ซึ่งแตกต่างจาก RPC ที่คุณมักจะต้องเพิ่มตรรกะอย่างชัดเจนมากขึ้น

การออกแบบแอปพลิเคชัน RESTful มักจะยากกว่ามากเพราะคุณต้องอธิบายสิ่งที่ซับซ้อนในลักษณะที่เรียบง่าย การอธิบายฟังก์ชั่นทั้งหมดโดยใช้ฟังก์ชั่น CRUD นั้นเป็นเรื่องยุ่งยาก แต่หลังจากทำแล้วชีวิตของคุณจะง่ายขึ้นมากและคุณจะพบว่าคุณจะเขียนวิธีที่สั้นกว่ามาก

สถาปัตยกรรม REST ที่ยับยั้งชั่งใจอีกอย่างหนึ่งคือไม่ใช้บริบทเซสชันเมื่อสื่อสารกับลูกค้า (ไร้สัญชาติ) หมายถึงข้อมูลทั้งหมดที่ต้องเข้าใจว่าใครคือลูกค้าและสิ่งที่เขาต้องการจะถูกส่งผ่านด้วยข้อความบนเว็บ การเรียกฟังก์ชั่นแต่ละครั้งเป็นการอธิบายด้วยตนเองไม่มีการสนทนากับลูกค้าก่อนหน้าซึ่งสามารถอ้างอิงได้ในข้อความ สำหรับลูกค้าไม่สามารถบอกได้ว่า "ให้หน้าถัดไป" เพราะคุณไม่มีเซสชั่นในการเก็บสิ่งที่เป็นหน้าก่อนหน้าและประเภทของหน้าที่คุณต้องการลูกค้าจะต้องพูดว่า "ชื่อของฉันคือ yuval รับ ฉันหน้า 2 ของโพสต์เฉพาะในฟอรั่มที่ระบุ " นั่นหมายถึงข้อมูลอีกเล็กน้อยจะต้องถ่ายโอนในการสื่อสาร แต่คิดว่าความแตกต่างระหว่างการค้นหาข้อบกพร่องที่รายงานจากฟังก์ชั่น "ให้ฉันหน้าถัดไป" ในทางตรงกันข้ามกับ "

แน่นอนว่ามันมีมากกว่านั้นมาก แต่สำหรับความเห็นของฉันนั่นเป็นแนวคิดหลักในช้อนชา

HTTP เป็นโปรโตคอลแอปพลิเคชัน REST เป็นชุดของกฎที่เมื่อติดตามจะช่วยให้คุณสามารถสร้างแอปพลิเคชันแบบกระจายที่มีชุดข้อ จำกัด ที่ต้องการโดยเฉพาะ

หากคุณกำลังมองหาข้อ จำกัด ที่สำคัญที่สุดของ REST ที่แยกแอปพลิเคชัน RESTful ออกจากแอปพลิเคชัน HTTP ใด ๆ ฉันจะพูดถึงข้อ จำกัด "คำอธิบายตัวเอง" และข้อ จำกัด ของสื่อสิ่งพิมพ์ (aka Hypermedia เป็น Engine ของ Application State (HATEOAS)) ที่สำคัญที่สุด.

ข้อ จำกัด ของคำอธิบายตัวเองต้องการคำขอ RESTful ที่จะอธิบายด้วยตนเองอย่างสมบูรณ์ในเจตนาของผู้ใช้ สิ่งนี้ทำให้ตัวกลาง (พร็อกซีและแคช) ดำเนินการกับข้อความได้อย่างปลอดภัย

ข้อ จำกัด HATEOAS เกี่ยวกับการเปลี่ยนแอปพลิเคชันของคุณให้เป็นเว็บลิงก์ที่สถานะปัจจุบันของลูกค้าอ้างอิงตามสถานที่ในเว็บนั้น มันเป็นแนวคิดที่ยุ่งยากและต้องการเวลาในการอธิบายมากกว่าที่ฉันมีในตอนนี้

ตามที่ฉันเข้าใจ REST บังคับให้ใช้คำสั่ง HTTP ที่มีอยู่ตามที่ตั้งใจไว้

ตัวอย่างเช่นฉันสามารถทำ:

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

แต่ส่วนที่เหลือฉันจะใช้วิธีการร้องขอ "DELETE" ลบความต้องการพารามิเตอร์ Param ของ "method"

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

ไม่มาก ...

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

เริ่มต้น REST ถูกอธิบายในบริบทของ HTTP แต่ไม่ จำกัด เฉพาะโปรโตคอลนั้น สถาปัตยกรรม RESTful สามารถขึ้นอยู่กับโปรโตคอลของเลเยอร์แอปพลิเคชันอื่น ๆ หากพวกเขามีคำศัพท์ที่หลากหลายและเหมือนกันสำหรับแอปพลิเคชันบนพื้นฐานของการถ่ายโอนสถานะการเป็นตัวแทนที่มีความหมาย แอปพลิเคชั่น RESTful ใช้ประโยชน์สูงสุดจากอินเทอร์เฟซที่มีอยู่แล้วที่กำหนดไว้ล่วงหน้าและความสามารถในตัวอื่น ๆ ที่มีให้โดยโปรโตคอลเครือข่ายที่เลือกและลดการเพิ่มคุณสมบัติเฉพาะแอปพลิเคชันใหม่

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

(Simple Object Access Protocol) มาตรฐานสำหรับข้อความเว็บเซอร์วิส ตาม XML, SOAP กำหนดรูปแบบซองจดหมายและกฎต่าง ๆ สำหรับการอธิบายเนื้อหา เห็น (กับ WSDL และ UDDI) เป็นหนึ่งในสามมาตรฐานพื้นฐานของบริการเว็บมันเป็นโปรโตคอลที่ต้องการสำหรับการแลกเปลี่ยนบริการเว็บ แต่ไม่เคยมีเพียงคนเดียว; ผู้เสนอของ REST บอกว่ามันเพิ่มความซับซ้อนที่ไม่จำเป็น

REST เป็นวิธีเฉพาะในการเข้าถึงการออกแบบระบบขนาดใหญ่ (เช่นเว็บ)

เป็นชุดของ 'กฎ' (หรือ 'ข้อ จำกัด ')

HTTP เป็นโปรโตคอลที่พยายามปฏิบัติตามกฎเหล่านั้น

REST = การถ่ายโอนสถานะผู้แทน

RESTเป็นชุดของกฎที่เมื่อติดตามจะช่วยให้คุณสามารถสร้างแอปพลิเคชันแบบกระจายที่มีชุดข้อ จำกัด ที่ต้องการโดยเฉพาะ

RESTเป็นโปรโตคอลในการแลกเปลี่ยนข้อความใด ๆ (XML, JSON ฯลฯ ) ที่สามารถใช้ HTTP เพื่อส่งข้อความเหล่านั้น

คุณสมบัติ:

มันไร้สัญชาติซึ่งหมายความว่าไม่มีการเชื่อมต่อระหว่างไคลเอนต์กับเซิร์ฟเวอร์ มันเป็นความรับผิดชอบของลูกค้าที่จะส่งบริบทไปยังเซิร์ฟเวอร์แล้วเซิร์ฟเวอร์สามารถจัดเก็บบริบทนี้เพื่อประมวลผลคำขอเพิ่มเติมของลูกค้า ตัวอย่างเช่นเซสชันที่ดูแลโดยเซิร์ฟเวอร์ถูกระบุโดยตัวระบุเซสชันที่ส่งผ่านโดยลูกค้า

ข้อดีของการไร้สัญชาติ:

1. บริการบนเว็บสามารถจัดการการโทรแต่ละวิธีแยกกันได้
2. บริการเว็บไม่จำเป็นต้องรักษาการโต้ตอบก่อนหน้าของลูกค้า
3. ทำให้การออกแบบแอปพลิเคชันง่ายขึ้น
4. HTTP นั้นเป็นโปรโตคอลไร้สัญชาติซึ่งแตกต่างจาก TCP ดังนั้น RESTful Web Services จึงทำงานร่วมกับโปรโตคอล HTTP ได้อย่างราบรื่น

ข้อเสียของการไร้สัญชาติ:

1. ต้องเพิ่มเลเยอร์พิเศษหนึ่งรายการในรูปแบบหัวเรื่องในทุกคำขอเพื่อรักษาสถานะของลูกค้า
2. เพื่อความปลอดภัยเราต้องเพิ่มข้อมูลส่วนหัวในทุกคำขอ

วิธีการ HTTP ได้รับการสนับสนุนโดย REST:

GET: / string / someotherstring เป็น idempotent และควรส่งคืนผลลัพธ์เดียวกันทุกครั้งที่มีการโทร

วาง: เหมือนกับ GET Idempotent และใช้เพื่ออัปเดตทรัพยากร

POST: ควรมี URL และเนื้อหาที่ใช้สำหรับการสร้างทรัพยากร การโทรหลายครั้งควรให้ผลลัพธ์ที่แตกต่างกันและควรสร้างผลิตภัณฑ์หลายรายการ

DELETE: ใช้เพื่อลบทรัพยากรบนเซิร์ฟเวอร์

ศีรษะ:

วิธี HEAD นั้นเหมือนกับ GET ยกเว้นว่าเซิร์ฟเวอร์จะต้องไม่ส่งคืนเนื้อความในการตอบกลับ ข้อมูลเมตาที่มีอยู่ในส่วนหัว HTTP เพื่อตอบสนองคำขอ HEAD SHOULD จะเหมือนกับข้อมูลที่ส่งเพื่อตอบสนองต่อคำขอ GET

ตัวเลือก:

วิธีนี้ช่วยให้ลูกค้าสามารถกำหนดตัวเลือกและ / หรือข้อกำหนดที่เกี่ยวข้องกับทรัพยากรหรือความสามารถของเซิร์ฟเวอร์โดยไม่ต้องมีการกระทำของทรัพยากรหรือการเริ่มต้นการดึงทรัพยากร

การตอบสนอง HTTP

ไปที่นี่เพื่อรับคำตอบทั้งหมด

ต่อไปนี้คือสิ่งสำคัญสองสามประการ: 200 - ตกลง 3XX - ข้อมูลเพิ่มเติมที่ต้องการจากการเปลี่ยนเส้นทางไคลเอนต์และ URL 400 - คำขอ
ไม่ ถูกต้อง401 - ไม่ได้รับอนุญาตให้เข้าถึง
403 - ต้องห้าม
คำขอถูกต้อง แต่เซิร์ฟเวอร์ปฏิเสธการดำเนินการ ผู้ใช้อาจไม่มีสิทธิ์ที่จำเป็นสำหรับทรัพยากรหรืออาจจำเป็นต้องมีบัญชีของการจัดเรียงบางอย่าง

404 - ไม่พบ
ทรัพยากรที่ร้องขอไม่พบ แต่อาจมีในอนาคต คำขอต่อมาโดยลูกค้าที่ได้รับอนุญาต

405 - วิธีการไม่อนุญาตวิธีการร้องขอไม่ได้รับการสนับสนุนสำหรับทรัพยากรที่ร้องขอ ตัวอย่างเช่นคำขอ GET บนแบบฟอร์มที่ต้องการข้อมูลที่จะแสดงผ่าน POST หรือคำขอ PUT บนทรัพยากรแบบอ่านอย่างเดียว

404 - ไม่พบคำขอ
500 - เซิร์ฟเวอร์ภายในล้มเหลว
502 - ข้อผิดพลาดเกตเวย์ไม่ดี

HTTP เป็นโปรโตคอลการสื่อสารที่ส่งข้อความผ่านเครือข่าย SOAP เป็นโปรโตคอลในการแลกเปลี่ยนข้อความที่ใช้ XML ซึ่งสามารถใช้ HTTP เพื่อขนส่งข้อความเหล่านั้น ส่วนที่เหลือเป็นโปรโตคอลในการแลกเปลี่ยนข้อความ (XML หรือ JSON) ใด ๆ ที่สามารถใช้ HTTP เพื่อส่งข้อความเหล่านั้น

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 HTTPก่อนที่จะมีการกำหนด REST ดังนั้นจึงง่ายต่อการใช้รูปแบบ REST API ด้วย HTTP

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

1. การโต้ตอบระหว่างเซิร์ฟเวอร์กับลูกค้าควรอธิบายผ่านทางไฮเปอร์เท็กซ์เท่านั้น

2.เซิร์ฟเวอร์และไคลเอนต์ควรอยู่คู่กันอย่างหลวม ๆ และไม่มีข้อสันนิษฐานเกี่ยวกับกันและกัน ลูกค้าควรทราบจุดเข้าใช้งานทรัพยากรเท่านั้น ข้อมูลการโต้ตอบควรถูกจัดเตรียมโดยเซิร์ฟเวอร์ในการตอบกลับ

3.เซิร์ฟเวอร์ไม่ควรจัดเก็บข้อมูลใด ๆ เกี่ยวกับบริบทคำขอ คำขอต้องเป็นอิสระและ idempotent (หมายความว่าหากมีการร้องขอซ้ำหลายครั้งผลลัพธ์ที่เหมือนกันจะถูกเรียกคืน)

และ HTTP เป็นเพียงโปรโตคอลการสื่อสาร (เครื่องมือ) ที่สามารถช่วยให้บรรลุเป้าหมายนี้

สำหรับข้อมูลเพิ่มเติมตรวจสอบลิงค์เหล่านี้:

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

ส่วนที่เหลือไม่จำเป็นต้องผูกติดอยู่กับHTTP บริการเว็บสงบเป็นเพียงบริการเว็บที่เป็นไปตามสถาปัตยกรรมสงบ

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

จากคุณไม่ทราบความแตกต่างระหว่าง HTTP และ REST

ดังนั้นสถาปัตยกรรม REST และโปรโตคอล HTTP 1.1 จึงเป็นอิสระจากกัน แต่โปรโตคอล HTTP 1.1 นั้นถูกสร้างขึ้นเพื่อเป็นโปรโตคอลในอุดมคติที่จะปฏิบัติตามหลักการและข้อ จำกัด ของ REST วิธีหนึ่งในการดูความสัมพันธ์ระหว่าง HTTP และ REST คือ REST นั้นคือการออกแบบและ HTTP 1.1 เป็นการใช้งานการออกแบบนั้น

REST API ต้องเป็นไฮเปอร์เท็กซ์ขับเคลื่อน

จากบล็อกของ Roy Fielding ต่อไปนี้เป็นวิธีการตรวจสอบว่าคุณกำลังสร้าง HTTP API หรือ REST API หรือไม่:

นักออกแบบ API โปรดทราบกฎต่อไปนี้ก่อนเรียก REST API ของคุณ:

• REST API ไม่ควรขึ้นอยู่กับโปรโตคอลการสื่อสารใด ๆ แม้ว่าการทำแผนที่ที่ประสบความสำเร็จกับโปรโตคอลที่กำหนดอาจขึ้นอยู่กับความพร้อมใช้งานของข้อมูลเมตาการเลือกวิธีการ ฯลฯ โดยทั่วไปองค์ประกอบโปรโตคอลใด ๆ ที่ใช้ URI สำหรับการระบุต้องอนุญาต รูปแบบ URI ใด ๆ ที่จะใช้เพื่อประโยชน์ในการระบุตัวตนนั้น [ความล้มเหลวที่นี่หมายถึงการระบุไม่ได้แยกออกจากการมีปฏิสัมพันธ์]
• REST API ไม่ควรมีการเปลี่ยนแปลงใด ๆ ในโปรโตคอลการสื่อสารนอกเหนือจากการกรอกข้อมูลหรือแก้ไขรายละเอียดของบิตมาตรฐานที่ไม่ได้ระบุของโปรโตคอลมาตรฐานเช่นวิธี PATCH ของ HTTP หรือฟิลด์ส่วนหัวลิงก์ วิธีแก้ปัญหาสำหรับการใช้งานที่ไม่สมบูรณ์ (เช่นเบราว์เซอร์ที่โง่พอที่จะเชื่อว่า HTML กำหนดชุดวิธีของ HTTP) ควรกำหนดแยกต่างหากหรืออย่างน้อยในภาคผนวกด้วยความคาดหวังว่าการแก้ปัญหาจะล้าสมัยในที่สุด [ความล้มเหลวที่นี่แสดงว่าส่วนต่อทรัพยากรเป็นแบบเฉพาะวัตถุไม่ใช่แบบทั่วไป]
• REST API ควรใช้ความพยายามเกือบทั้งหมดในการกำหนดประเภทสื่อที่ใช้สำหรับการแสดงทรัพยากรและการขับเคลื่อนสถานะของแอปพลิเคชันหรือในการกำหนดชื่อที่มีความสัมพันธ์เพิ่มเติมและ / หรือการเปิดใช้งานมาร์คอัพแบบไฮเปอร์เท็กซ์ ความพยายามใด ๆ ที่ใช้อธิบายว่าวิธีใดที่จะใช้กับสิ่งที่ URIs สนใจควรกำหนดไว้อย่างสมบูรณ์ภายในขอบเขตของกฎการประมวลผลสำหรับประเภทสื่อ (และในกรณีส่วนใหญ่จะถูกกำหนดโดยประเภทสื่อที่มีอยู่แล้ว) [ความล้มเหลวที่นี่หมายถึงว่าข้อมูลนอกวงกำลังผลักดันการมีปฏิสัมพันธ์แทนไฮเปอร์เท็กซ์)
• REST API ต้องไม่กำหนดชื่อหรือลำดับชั้นของทรัพยากรคงที่ (การเชื่อมต่อที่ชัดเจนของไคลเอ็นต์และเซิร์ฟเวอร์) เซิร์ฟเวอร์ต้องมีอิสระในการควบคุมเนมสเปซของตนเอง อนุญาตให้เซิร์ฟเวอร์สอนลูกค้าเกี่ยวกับวิธีการสร้าง URIs ที่เหมาะสมเช่นทำในรูปแบบ HTML และเทมเพลต URI โดยกำหนดคำแนะนำเหล่านั้นภายในประเภทสื่อและความสัมพันธ์ของลิงก์ [ความล้มเหลวที่นี่หมายถึงว่าลูกค้ากำลังสมมติโครงสร้างทรัพยากรเนื่องจากข้อมูลนอกแบนด์เช่นมาตรฐานโดเมนเฉพาะซึ่งเป็นข้อมูลเชิงเทียบได้กับการทำงานของ RPC]
• REST API ไม่ควรมีทรัพยากร“ พิมพ์” ที่สำคัญต่อลูกค้า ผู้เขียนข้อมูลจำเพาะอาจใช้ประเภททรัพยากรเพื่ออธิบายการใช้งานเซิร์ฟเวอร์หลังส่วนต่อประสาน แต่ประเภทเหล่านั้นต้องไม่เกี่ยวข้องและไม่สามารถมองเห็นได้กับลูกค้า ประเภทเท่านั้นที่มีความสำคัญต่อลูกค้าคือประเภทสื่อโฆษณาในปัจจุบันและชื่อความสัมพันธ์ที่ได้มาตรฐาน [เหมือนกัน]
• ควรป้อน REST API โดยไม่มีความรู้ล่วงหน้านอกเหนือจาก URI เริ่มต้น (บุ๊กมาร์ก) และชุดของประเภทสื่อมาตรฐานที่เหมาะสมสำหรับผู้ชมที่ต้องการ (กล่าวคือคาดว่าจะเข้าใจโดยลูกค้าที่อาจใช้ API) จากจุดนั้นการเปลี่ยนสถานะแอปพลิเคชันทั้งหมดจะต้องขับเคลื่อนโดยการเลือกไคลเอ็นต์ของตัวเลือกที่เซิร์ฟเวอร์จัดเตรียมไว้ซึ่งมีอยู่ในการรับรองที่ได้รับหรือโดยนัยโดยการจัดการของผู้ใช้ในการเป็นตัวแทนเหล่านั้น ช่วงการเปลี่ยนภาพอาจถูกกำหนด (หรือ จำกัด โดย) ความรู้ของลูกค้าเกี่ยวกับประเภทสื่อและกลไกการสื่อสารทรัพยากรซึ่งทั้งสองอย่างนี้อาจได้รับการปรับปรุงให้ดีขึ้น (เช่นรหัสตามความต้องการ) [ความล้มเหลวที่นี่หมายถึงว่าข้อมูลนอกวงกำลังผลักดันการมีปฏิสัมพันธ์แทนไฮเปอร์เท็กซ์)