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

     ความต้องการของเราจริงๆแล้วแค่ต้องการเรียกใช้โปรแกรมและรับผลลัพธ์กลับแบบง่ายๆเท่านั้น – ตัวอย่างเช่น ในการใช้งานเว็บเราเพียงแค่แจ้ง URL ให้บราวเซอร์ บราวเซอร์จะส่งคำขอไปยังเว็บเซิร์ฟเวอร์ตามที่อยู่ที่ระบุใน URL จากนั้นเว็บเซิร์ฟเวอร์ก็จะส่งเนื้อหากลับมาในรูปแบบโปรโตคอล HTML และบราวเซอร์ก็จะนำเนื้อหานั้นมาแสดงให้เราดู จึงเป็นที่มาของสถาปัตยกรรมซอฟต์แวร์ที่เรียกว่า REST ซึ่งย่อมาจาก representational state transfer เพื่อใช้กับเว็บแอพพลิเคชั่น (distributed hypermedia application) โดยมองว่าบริการ เช่น เว็บ คือกลุ่มของการให้บริการที่ไม่ได้ผูกพันกัน โดยผู้ใช้งานเข้าถึงแต่ละบริการผ่านทางลิงค์ (hypermedia link) ดังนั้นแต่ละบริการเพียงแค่ส่งต่อผู้ใช้งานไปตามลิงค์ที่ระบุโดยไม่ต้องจัดการหรือเก็บสถานะของผู้ใช้งาน

     REST ถูกออกแบบมาเพื่อแก้ปัญหาที่เกิดจากการใช้งานเว็บแอพพลิเคชั่น โดยจัดเตรียมรูปแบบการเชื่อมต่อที่ใช้ง่าย เชื่อถือได้ รองรับการใช้งานที่มากขึ้นได้ และขยายขีดความสามารถได้ (สังเกตุว่าเว็บที่เราใช้ในปัจจุบันก็สอดคล้องตามหลักการนี้เช่นกัน) REST ใช้ URI  (uniform resource identifier) ในการระบุชื่อบริการและทรัพยากรที่ต้องการจัดการ ช่วยให้การระบุชื่อบริการทำได้ง่ายและมีความชัดเจน REST ใช้โปรโตคอล HTML ในการ ค้นคืน สร้าง ปรับปรุง และ ลบ ทรัพยากรที่กำหนดผ่านเมธอด get post put และ delete และยังสามารถระบุข้อมูลเมตาที่อยู่ในส่วนหัวของข้อมูลที่จะส่งไปยังผู้ให้บริการได้ด้วย เช่น ระบุรูปแบบข้อมูลตอบกลับที่ต้องการ ระบุข้อมูลผู้ใช้งานที่ส่งคำขอ หรือ ระบุการอนุญาติในการใช้งาน 

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

     REST ตอบกลับได้หลายรูปแบบแต่รูปแบบที่นิยมใช้คือ XML HTML หรือ JSON เพราะเป็นการส่งข้อมูลในแบบที่มีคำอธิบายในตัวเอง (self-descriptive hypermedia document) รูปแบบ HTML จะถูกใช้ในกรณีที่ผลลัพธ์ถูกส่งกลับแสดงผลในโปรแกรมบราวเซอร์ รูปแบบ XML เป็นรูปแบบที่ใช้งานมานานแล้วมักจะใช้ในกรณีที่ต้องอธิบายออบเจกต์ที่ซับซ้อนอย่างละเอียด รูปแบบ JSON จะถูกใช้เมื่อเราต้องการให้ออบเจกต์ถูกวิเคราะห์ (parsing) โดยบราวเซอร์หรือโหนด เช่น ใน NodeJS เพราะออบเจกต์ JSON ก็คือออบเจกต์ Java Script นั่นเอง นอกจากนี้ข้อมูลตอบกลับจะแบ่งออกเป็นส่วนควบคุม (header) และส่วนเนื้อหา (body) ข้อมูลในส่วนควบคุมจะประกอบไปด้วยข้อมูลเมตาต่างๆซึ่งข้อมูลที่สำคัญคือรหัสสถานะของการประมวลผล (status code) ซึ่งเป็นรหัสมาตรฐาน เช่น รหัส 200 หมายถึงการประมวลผลสำเร็จ หรือ รหัส 404 หมายถึงไม่พบทรัพยากรที่ต้องการ 

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

     REST ต้องมีการจัดการเวอร์ชั่น เพราะผู้ให้บริการ API ส่วนมากจะมีการปรับปรุง API อยู่เสมอ ดังนั้นเพื่อไม่ให้การปรับปรุงกระทบกับลูกค้าจึงต้องมีการจัดการเวอร์ชั่นของ API โดยวิธีการจัดการมีหลายวิธี (1) จัดการผ่านการเข้าถึงโดยใช้ URI เช่น https://myserver.com/api/v1/user และ https://myserver.com/api/v2/user เป็นต้น (2) โดยการระบุเวอร์ชั่นที่จะใช้งาน เช่น https://myserver.com/api/user/?v=1 (3) กำหนดเวอร์ชั่นที่จะใช้ในส่วนหัว (header) ของคำขอซึ่งจะไม่กระทบกับคำขอที่ลูกค้าใช้อยู่หากลูกค้าต้องการเปลี่ยนเวอร์ชั่น

      REST ต้องการการอนุญาติใช้งาน เพราะบริการเป็นการใช้งานแบบทางไกล (remote) ดังนั้นเฉพาะผู้ใช้งานที่ได้รับอนุญาติเท่านั้นจึงจะสามารถใช้บริการได้ การอนุญาติใช้งานยังสามารถนำมาใช้ในการนับจำนวนการใช้งานได้ด้วย การอนุญาติสามารถทำได้โดยใช้การอนุญาติตามมาตรฐานโปรโตคอล HTTP/HTTPS (HTTP basic authentication over HTTPS) หรือใช้คุกกี๊ หรือใช้การอนุญาติตามมาตรฐานเปิด เช่น OAuth หรือ OAuth2

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

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