REST ( Representational State Transfer ) เป็นรูปแบบสถาปัตยกรรมซอฟต์แวร์ที่สร้างขึ้นเพื่ออธิบายการออกแบบและเป็นแนวทางในการพัฒนาสถาปัตยกรรมสำหรับเวิลด์ไวด์เว็บ REST กำหนดข้อจำกัดชุดหนึ่งสำหรับวิธีการทำงานของสถาปัตยกรรมของ ระบบ ไฮเปอร์มีเดีย แบบกระจายขนาดใหญ่ ระดับอินเทอร์เน็ตเช่น เว็บ รูปแบบสถาปัตยกรรม REST เน้นอินเทอร์เฟซ ที่เป็นมาตรฐาน การใช้งานส่วนประกอบ อย่างอิสระ ความ สามารถในการ ปรับขนาดของการโต้ตอบระหว่างส่วนประกอบ และการสร้างสถาปัตยกรรมแบบเลเยอร์เพื่อส่งเสริมการแคช เพื่อลด ความหน่วงแฝงที่ผู้ใช้รับรู้บังคับใช้ความปลอดภัยและห่อหุ้มระบบเดิม^{[ 1 ]}

REST ถูกนำมาใช้ทั่วทั้งอุตสาหกรรมซอฟต์แวร์เพื่อสร้างแอปพลิเคชันบนเว็บที่เชื่อถือได้และไม่มี สถานะ แอปพลิเค ชันที่ปฏิบัติตามข้อจำกัดทางสถาปัตยกรรมของ RESTอาจถูกอธิบายอย่างไม่เป็นทางการว่าRESTfulแม้ว่าคำนี้มักจะเกี่ยวข้องกับการออกแบบAPIที่ใช้HTTPและสิ่งที่ถือว่าเป็นแนวปฏิบัติที่ดีที่สุดเกี่ยวกับ "คำกริยา" ( วิธีการ HTTP ) ที่ทรัพยากรตอบสนอง ในขณะที่แทบไม่มีส่วนเกี่ยวข้องกับ REST ตามที่กำหนดไว้แต่เดิม และมักจะขัดแย้งกับแนวคิดด้วยซ้ำ^{[ 2 ]}

คำว่า " การถ่ายโอนสถานะแบบแสดงผล" (Representational State Transfer ) ถูกนำเสนอและนิยามขึ้นในปี 2000 โดยนักวิทยาศาสตร์คอมพิวเตอร์รอย ฟิลดิงในวิทยานิพนธ์ระดับปริญญาเอกของเขา หมายความว่า เซิร์ฟเวอร์จะตอบกลับด้วยการแสดงผลของทรัพยากร (ในปัจจุบัน ส่วนใหญ่จะเป็น เอกสาร HTML ) และทรัพยากรนั้นจะประกอบด้วย ลิงก์ ไฮเปอร์มีเดียที่สามารถคลิกเพื่อเปลี่ยนแปลงสถานะของระบบได้ คำขอใดๆ ก็ตามจะได้รับการแสดงผลของทรัพยากรนั้นกลับคืนมา และเป็นเช่นนี้เรื่อยไป

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

เว็บเริ่มเข้ามามีบทบาทในชีวิตประจำวันในช่วงปี 1993–1994 เมื่อเว็บไซต์สำหรับใช้งานทั่วไปเริ่มเปิดให้บริการ^{[ 3 ]}ในขณะนั้น มีเพียงคำอธิบายที่กระจัดกระจายเกี่ยวกับสถาปัตยกรรมของเว็บ และมีแรงกดดันภายในชุมชนให้ตกลงกันในมาตรฐานสำหรับโปรโตคอลอินเทอร์เฟซของเว็บ ตัวอย่างเช่น มีการเพิ่มส่วนขยายทดลองหลายอย่างลงในโปรโตคอลการสื่อสาร (HTTP) เพื่อรองรับพร็อกซีและมีการเสนอส่วนขยายเพิ่มเติม แต่มีความจำเป็นต้องมีสถาปัตยกรรมเว็บที่เป็นทางการเพื่อประเมินผลกระทบของการเปลี่ยนแปลงเหล่านี้^{[ 4 ]}

กลุ่มทำงาน W3C และIETF ร่วมกันเริ่มทำงานในการสร้างคำอธิบายอย่างเป็นทางการ ของ มาตรฐานหลักสามประการของเว็บ ได้แก่URI , HTTPและHTMLรอย ฟิลดิง มีส่วนร่วมในการสร้างมาตรฐานเหล่านี้ (โดยเฉพาะ HTTP 1.0 และ 1.1 และ URI) และในช่วงหกปีต่อมา เขาได้สร้างรูปแบบสถาปัตยกรรม REST ทดสอบข้อจำกัดของรูปแบบดังกล่าวกับมาตรฐานโปรโตคอล ของเว็บ และใช้รูปแบบดังกล่าวเป็นวิธีการในการกำหนดการปรับปรุงทางสถาปัตยกรรม และเพื่อระบุความไม่ตรงกันทางสถาปัตยกรรม ฟิลดิงได้กำหนด REST ไว้ในวิทยานิพนธ์ปริญญาเอกปี 2000 ของเขาเรื่อง "รูปแบบสถาปัตยกรรมและการออกแบบสถาปัตยกรรมซอฟต์แวร์บนเครือข่าย" ^{[ 1 ] [ 5 ]}ที่UC Irvine

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

โดยธรรมชาติแล้ว รูปแบบสถาปัตยกรรมนั้นเป็นอิสระจากการใช้งานเฉพาะใดๆ และในขณะที่ REST ถูกสร้างขึ้นเป็นส่วนหนึ่งของการพัฒนามาตรฐานเว็บ การใช้งานเว็บก็ไม่ได้ปฏิบัติตามข้อจำกัดทุกประการในรูปแบบสถาปัตยกรรม REST ความไม่ตรงกันอาจเกิดขึ้นเนื่องจากความไม่รู้หรือการมองข้าม แต่การมีอยู่ของรูปแบบสถาปัตยกรรม REST หมายความว่าสามารถระบุความไม่ตรงกันเหล่านั้นได้ก่อนที่จะกลายเป็นมาตรฐาน ตัวอย่างเช่น Fielding ระบุว่าการฝังข้อมูลเซสชันใน URI เป็นการละเมิดข้อจำกัดของ REST ซึ่งอาจส่งผลเสียต่อการแคชร่วมกันและความสามารถในการปรับขนาดของเซิร์ฟเวอร์คุกกี้ HTTPยังละเมิดข้อจำกัดของ REST ^{[ 4 ]}เนื่องจากอาจไม่ตรงกับสถานะแอปพลิเคชันของเบราว์เซอร์ ทำให้ไม่น่าเชื่อถือ นอกจากนี้ยังมีข้อมูลที่ไม่โปร่งใสซึ่งอาจเป็นข้อกังวลด้านความเป็นส่วนตัวและความปลอดภัย

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

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

ข้อจำกัดของรูปแบบสถาปัตยกรรม REST ส่งผลต่อคุณสมบัติทางสถาปัตยกรรมดังต่อไปนี้: ^{[ 1 ] [ 7 ]}

• ประสิทธิภาพในการโต้ตอบของส่วนประกอบ ซึ่งอาจเป็นปัจจัยหลักในประสิทธิภาพที่ผู้ใช้รับรู้และประสิทธิภาพของเครือข่าย^{[ 8 ]}
• ความสามารถในการปรับขนาดที่ช่วยให้รองรับส่วนประกอบจำนวนมากและการโต้ตอบระหว่างส่วนประกอบต่างๆ ได้
• ความเรียบง่ายของอินเทอร์เฟซที่เป็นมาตรฐานเดียวกัน
• ความสามารถในการปรับเปลี่ยน ( หรือขยายขีดความสามารถ ) ของส่วนประกอบต่างๆ เพื่อตอบสนองความต้องการที่เปลี่ยนแปลงไป (แม้ในขณะที่แอปพลิเคชันกำลังทำงานอยู่)
• ตัวแทนบริการสามารถมองเห็นการสื่อสารระหว่างส่วนประกอบต่างๆ ได้อย่างชัดเจน
• ความสามารถในการเคลื่อนย้ายส่วนประกอบต่างๆ โดยการย้ายโค้ดโปรแกรมไปพร้อมกับข้อมูล
• ความน่าเชื่อถือในการต้านทานต่อความล้มเหลวในระดับระบบในกรณีที่เกิดความล้มเหลวภายในส่วนประกอบ ตัวเชื่อมต่อ หรือข้อมูล^{[ 8 ]}

รูปแบบสถาปัตยกรรม REST กำหนดข้อจำกัดหลัก 6 ประการ^{[ 7 ] [ 9 ]}เมื่อนำข้อจำกัดเหล่านี้ไปใช้กับสถาปัตยกรรมของระบบ จะทำให้ระบบมีคุณสมบัติที่ไม่ใช่ฟังก์ชันการทำงาน ที่พึงประสงค์ เช่น ประสิทธิภาพ ความสามารถในการขยายขนาด ความเรียบง่าย ความสามารถในการปรับเปลี่ยน การมองเห็น การพกพา และความน่าเชื่อถือ^{[ 1 ]}

ข้อจำกัด REST อย่างเป็นทางการมีดังต่อไปนี้: ^{[ 10 ]}

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

ข้อจำกัดอินเทอร์เฟซที่เป็นเอกภาพเป็นพื้นฐานในการออกแบบระบบ RESTful ใดๆ^{[ 1 ]}ช่วยลดความซับซ้อนและแยกส่วนสถาปัตยกรรม ซึ่งทำให้แต่ละส่วนสามารถพัฒนาได้อย่างอิสระ ข้อจำกัดสี่ประการสำหรับอินเทอร์เฟซที่เป็นเอกภาพนี้คือ:

• การระบุทรัพยากรในคำขอ: ทรัพยากรแต่ละรายการจะถูกระบุในคำขอโดยใช้URIตัวทรัพยากรเองนั้นแยกออกจากข้อมูลที่ส่งกลับไปยังไคลเอ็นต์โดยทางแนวคิด ตัวอย่างเช่น เซิร์ฟเวอร์อาจส่งข้อมูลจากฐานข้อมูลในรูปแบบHTML , XMLหรือJSONซึ่งไม่มีรูปแบบใดเป็นรูปแบบการแสดงผลภายในของเซิร์ฟเวอร์
• การจัดการทรัพยากรผ่านการแสดงผล: เมื่อไคลเอ็นต์ถือครองการแสดงผลของทรัพยากร รวมถึงเมตาเดตาที่แนบมาด้วย ไคลเอ็นต์จะมีข้อมูลเพียงพอที่จะแก้ไขหรือลบสถานะของทรัพยากรได้
• ข้อความที่อธิบายตัวเองได้: แต่ละข้อความประกอบด้วยข้อมูลเพียงพอที่จะอธิบายวิธีการประมวลผลข้อความ ตัวอย่างเช่น สามารถระบุตัวแยกวิเคราะห์ที่จะเรียกใช้ได้โดยใช้ประเภทสื่อ^{[ 1 ]}
• ไฮเปอร์มีเดียเป็นกลไกของสถานะแอปพลิเคชัน ( HATEOAS ) – เมื่อเข้าถึง URI เริ่มต้นสำหรับแอปพลิเคชัน REST ซึ่งเปรียบเสมือนผู้ใช้เว็บที่เข้าถึงหน้าแรกของเว็บไซต์ ไคลเอนต์ REST ควรจะสามารถใช้ลิงก์ที่เซิร์ฟเวอร์จัดเตรียมไว้แบบไดนามิกเพื่อค้นหาทรัพยากรที่มีอยู่ทั้งหมดที่ต้องการได้ เมื่อการเข้าถึงดำเนินไป เซิร์ฟเวอร์จะตอบกลับด้วยข้อความที่มีไฮเปอร์ลิงก์ไปยังทรัพยากรอื่นๆ ที่มีอยู่ในปัจจุบัน ไม่จำเป็นต้องให้ไคลเอนต์เขียนโค้ดแบบตายตัวเกี่ยวกับโครงสร้างของเซิร์ฟเวอร์^{[ 11 ]}

มีการพัฒนารูปแบบจำลองหลายแบบเพื่อช่วยจำแนกประเภท API ของ HTTP ตามการปฏิบัติตามหลักการออกแบบ REST ต่างๆ เช่น

• แบบจำลองวุฒิภาวะของ ริชาร์ดสัน
• การจำแนกประเภทของ API ที่ใช้ HTTP ^{[ 12 ]}
• แบบจำลองความสมบูรณ์WS ^{3 [ 13 ]}

• URL ที่สะอาดตา  – URL ที่ออกแบบมาเพื่อเพิ่มความสะดวกในการใช้งานเว็บไซต์
• เครือข่ายส่งเนื้อหา (Content Delivery Network)  – ชั้นระบบนิเวศอินเทอร์เน็ตที่ช่วยแก้ไขปัญหาคอขวด
• โปรโตคอลแอปพลิเคชันโดเมน (DAP)
• รายการรูปแบบ URI  – ตัวระบุเนมสเปซที่กำหนดโดย IANA
• ไมโครเซอร์วิส  – กลุ่มของบริการที่เชื่อมโยงกันอย่างหลวมๆ ซึ่งใช้ในการสร้างแอปพลิเคชันคอมพิวเตอร์
• ภาพรวมของภาษาที่ใช้ในการอธิบาย RESTful API  – คำอธิบายเกี่ยวกับภาษาคอมพิวเตอร์
• สถาปัตยกรรมที่เน้นทรัพยากร  – รูปแบบสถาปัตยกรรมในการออกแบบซอฟต์แวร์
• การประมวลผลที่เน้นทรัพยากร  – รูปแบบสถาปัตยกรรมในการออกแบบซอฟต์แวร์
• สถาปัตยกรรมเชิงบริการ  – รูปแบบสถาปัตยกรรมในการออกแบบซอฟต์แวร์
• สถาปัตยกรรมที่มุ่งเน้นเว็บ  – รูปแบบสถาปัตยกรรมในการออกแบบซอฟต์แวร์
• บริการเว็บ  – บริการที่ให้บริการระหว่างอุปกรณ์อิเล็กทรอนิกส์ผ่านทางอินเทอร์เน็ต

• Pautasso, Cesare; Wilde, Erik; Alarcon, Rosa (2014), REST: หัวข้อวิจัยขั้นสูงและการประยุกต์ใช้ในทางปฏิบัติ , Springer, ISBN 9781461492986
• Pautasso, Cesare; Zimmermann, Olaf; Leymann, Frank (เมษายน 2551), "บริการเว็บแบบ RESTful เทียบกับบริการเว็บขนาดใหญ่", รายงานการประชุมนานาชาติว่าด้วยเวิลด์ไวด์เว็บครั้งที่ 17 , หน้า  805–814 , doi : 10.1145/1367497.1367606 , ISBN 9781605580852, S2CID  207167438
• Ferreira, Otavio (พ.ย. 2552), Semantic Web Services: A RESTful Approach , IADIS, ISBN 978-972-8924-93-5
• ฟาวเลอร์, มาร์ติน (18 มีนาคม 2010). "แบบจำลองความสมบูรณ์ของริชาร์ดสัน: ขั้นตอนสู่ความรุ่งโรจน์ของ REST" . martinfowler.com . สืบค้นเมื่อ26 มิถุนายน 2017 .