REST กับ RESTful และบริการเว็บ“ ปกติ”

21

ฉันได้อ่านคำจำกัดความและการอภิปรายเกี่ยวกับแอปพลิเคชัน REST และ / หรือ RESTful แล้ว แต่ฉันยังไม่เข้าใจความหมายที่แท้จริงของมัน

ฉันมักจะทำงานกับแอพที่ดึงข้อมูลผ่าน GET หรือส่งข้อมูลผ่าน POST ไปยังเว็บเซอร์วิสบางตัว (โดยปกติจะเป็นสคริปต์ PHP) จากนั้นรับข้อมูลจากฐานข้อมูลหรือเขียนลงในฐานข้อมูล

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

นอกจากนี้บางคนกำลังพูดถึง REST และบางคนเกี่ยวกับแอป RESTful ฉันพบว่าคำว่า REST หมายถึงแนวคิดเชิงทฤษฎีในขณะที่ RESTful จะใช้เมื่อเราพูดถึงแอพที่เฉพาะเจาะจง ถูกต้องหรือมีความแตกต่างระหว่างแอพ REST และ RESTful จริงหรือไม่?

— deviDave
แหล่งที่มา

1

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

— Neil

@ Neil ฉันอยู่อีกด้านหนึ่ง - แอพมือถือ มันเป็นลูกค้าที่ใช้บริการเว็บและสื่อสารกับมันผ่านทาง POST และ GET บริการบนเว็บทั้งหมดถูกสร้างขึ้นโดยคนอื่นและทั้งหมดที่ฉันทำคือใช้พวกเขา แต่คำศัพท์ทำให้ฉันสับสน ดังนั้นถ้าฉันใช้ช่องสัญญาณ HTTP และวัตถุ HttpGet / HttpPost ฉันจะจัดการกับแอป RESTful ใช่ไหม

— deviDave

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

— Neil

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

— deviDave

2

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

— Neil

13

คุณลักษณะที่สำคัญของแอปพลิเคชัน RESTful คือ: การสื่อสารทั้งหมดผ่าน http GET, POST, PUT, DELETE และไอเท็มทั้งหมดจะถูกส่งผ่าน URL มาตรฐานของแบบฟอร์มhttp://your.site.com/salesapp/salesperson/0000001/detailsเช่นเฉพาะ URL บริสุทธิ์ที่ไม่มีพารามิเตอร์ ฯลฯ URL จะระบุสิ่งที่ GET ได้รับ , POST, PUT, DELETE ระบุสิ่งที่คุณต้องการจะทำ

เหตุผลหลักในการทำเช่นนี้คือคุณมีบริการไร้สัญชาติโดยอัตโนมัติซึ่งสามารถโหลดสมดุลล้มเหลวเป็นต้น

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

— James Anderson
แหล่งที่มา

โอ้ตอนนี้ฉันยังไม่ได้ใช้ PUT หรือ DELETE (โดยปกติแล้วแอปมือถือจะทำแค่ GET และ POST เท่านั้น) แต่นี่ดูเหมือนว่าฉันได้ทำไปแล้วและกำลังทำอยู่ในขณะนี้ เป็นเพียงว่าลูกค้าไม่ได้ใช้เงื่อนไข REST * แต่เป็น "บริการเว็บ" และ "สคริปต์ PHP"

— deviDave

2

James คุณช่วยอธิบายได้ไหมว่าทำไมต้องหลีกเลี่ยงพารามิเตอร์การสืบค้น ตัวอย่างเช่นฉันจะแสดงให้เห็นได้อย่างไรว่าฉันต้องการกรองทรัพยากรในลักษณะเฉพาะโดยไม่ต้องแนะนำลำดับชั้นที่ผิดพลาด

— Gary Rowe

3

@GaryRowe: URL (ไม่มีพารามิเตอร์) จะระบุทรัพยากรที่คุณต้องการจัดการ คุณยังสามารถมีพารามิเตอร์ได้ แต่สิ่งเหล่านี้ไม่ได้ใช้ในการระบุทรัพยากร ตัวอย่าง GET ในไดเรกทอรี (URL ที่ลงท้ายด้วย /) ควรส่งคืนรายการทรัพยากรในไดเรกทอรี อาจใช้พารามิเตอร์ใน URL เพื่อระบุตัวกรองหรือเรียงลำดับหรือสิ่งที่คล้ายกัน

— Martin York

1

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

— Gary Rowe

REST ไม่ต้องการให้แอปใช้ URL ไม่จำเป็นต้องให้คุณมีคำกริยาเช่น GET, POST, DELETE ฯลฯ อย่างไรก็ตามสำหรับ WebApp นั้น URL เป็นตัวเลือกเดียวและคำกริยาข้างต้น

— นาวาซ

6

REST ย่อมาจาก Representative State Transfer หากซอฟต์แวร์ของคุณเป็นไปตามข้อ จำกัด ของ REST แสดงว่าเป็นซอฟต์แวร์ที่สงบ

ตอนนี้ที่ฉันได้อ่านวิกิพีเดียอย่างไร้ยางอายหมายความว่าอย่างไร มันหมายถึงการใช้คำสั่ง HTTP inbuilt เช่น GET, POST, PUT, DELETE และ rarer อื่น ๆ สองสามตัวเพื่อสื่อสารไปมาระหว่างไคลเอนต์และเซิร์ฟเวอร์

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

บทความ Wikipedia เกี่ยวกับเรื่องนี้ดีมากจริง ๆ ดังนั้นฉันจะหยุดที่นี่

— Martijn Verburg
แหล่งที่มา

จนถึงตอนนี้ฉันใช้ GET (HttpGet) เพื่อดึงเนื้อหาและ POST (HttpPost) เพื่อป้อน / เปลี่ยนเนื้อหาของฐานข้อมูล ฉันส่งสิ่งนี้เป็นพารามิเตอร์ให้กับ HttpPost และสคริปต์ PHP บนเว็บเซิร์ฟเวอร์แปลงพารามิเตอร์เหล่านี้เป็นรหัส SQL นี่เป็นแอปที่เงียบสงบหรือไม่ ฉันสนใจในแนวคิดไม่ใช่สคริปต์ PHP ที่ทำได้ดีเพียงใด ฉันไม่ได้ทำมัน

— deviDave

2

ฉันจะตรวจสอบการใช้ PUT ในกรณีที่คุณกำลังแทนที่เนื้อหา REST ที่ใช้สำนวนมากกว่าการใช้ POST

— Martijn Verburg

ใช่ในกรณีเช่นนี้ฉันจะใช้ PUT

— deviDave

+1 สำหรับการสังเกตว่า GET ต้องดำเนินการอย่างถูกต้อง (นั่นคือ idempotent) ข้อผิดพลาดพื้นฐานดังกล่าวในวันแรก ๆ

— Gary Rowe

@deviDave คุณอาจต้องการตรวจสอบ PATCH ที่ออกแบบมาเพื่อปรับปรุงส่วนของทรัพยากร ในฐานะที่เป็น Martin ชี้ให้เห็นอย่างถูกต้อง PUT มีไว้สำหรับการแทนที่ทรัพยากรทั้งหมด

— Gary Rowe

4

ก่อนเพิ่มเติมคำถามที่เกี่ยวข้องอาจช่วยคุณได้

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

เว็บแอปพลิเคชั่นหลายแห่งอ้างว่าเป็น RESTful แต่จริงๆแล้วเป็นเพียงบางส่วนที่สอดคล้องกับข้อ จำกัด ของ REST (เนื่องจาก Martijn Verburg ได้อ้างถึงในคำตอบของเขาด้วย) ฉันจะแสดงรายการไว้ที่นี่ แต่ฉันขอแนะนำให้คุณอ่านบทความ:

ไคลเอนต์เซิร์ฟเวอร์
แคชได้
ระบบเลเยอร์
รหัสตามต้องการ (ไม่บังคับ)

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

ลูกค้าของคุณจะได้รับ:

ใช้คำกริยา HTTP (เช่น GET, POST, PUT, DELETE, OPTIONS, PATCH) เพื่อดำเนินการที่เกี่ยวข้อง
ข้อเสนอยอมรับส่วนหัวและเข้าใจส่วนหัวประเภทเนื้อหา (เช่นคุณได้รับ XML บางอย่างที่คุณไม่เคยเห็นมาก่อน แต่คุณสามารถใช้ XSD ที่อ้างอิงเพื่อสร้างแบบจำลองโดเมนฝั่งไคลเอ็นต์เพื่อนำเสนอให้กับผู้ใช้ของคุณ)
ติดตามลิงก์ที่นำเสนอในประเภทเนื้อหาที่คุณเข้าใจ (เช่นให้ผู้ใช้หรือแอปพลิเคชันของคุณอนุมานว่า<link rel="pay" href="http://example.org/orders(1)/payment">ใน HTML เป็นการแสดงสถานะการเปลี่ยนสถานะเพื่อสร้างทรัพยากรการชำระเงินผ่าน POST พร้อมเนื้อหาที่มี XML บางตัวที่แสดงรายละเอียดการชำระเงินเช่นหมายเลขบัตรเครดิต จำนวนและอื่น ๆ )
ตอบสนองอย่างถูกต้องกับรหัสสถานะ HTTP ที่หลากหลาย

หากทำตามข้างต้นอาจถือว่าเป็นลูกค้า REST คุณอาจต้องการเรียกว่า "แอป RESTful" แต่นั่นก็หมายความว่าคุณกำลังใช้ REST ในฝั่งไคลเอ็นต์ซึ่งไม่ถูกต้องดังนั้นควรหลีกเลี่ยง ระยะ

— Gary Rowe
แหล่งที่มา

3

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

ข้อ จำกัด เหล่านี้ทำให้แน่ใจได้ว่าคำขอทั้งหมดเป็น idempotent (การส่งหลายครั้งไม่มีผลพิเศษใด ๆ กับการส่งครั้งเดียว) สิ่งนี้มีความสำคัญเนื่องจากเครือข่ายอาจล้มเหลวได้ตลอดเวลาและไม่ส่งคำขอหรือตอบสนองใด ๆ และด้วยคำขอ idempotent ที่คุณเพิ่งส่งอีกครั้งและไม่ต้องทำการกู้คืนที่ซับซ้อน

— Jan Hudec
แหล่งที่มา

โหวตขึ้นสำหรับวรรค 1 รัดกุมมาก ขอบคุณ!

— deviDave

อีกสิ่งหนึ่งที่เจ้าเพื่อดูว่าฉันได้รับมันถูกต้อง ถ้าฉัน (แอพของฉัน) เป็นไคลเอนต์ของบริการ REST ฉันเป็นลูกค้าไม่ได้ใช้บริการถ้า RESTful หรือไม่เพราะการเข้ารหัสของฉันจะเหมือนกันเสมอ (httpget, httppost, ฯลฯ )? หลักการนี้สำคัญสำหรับเจ้าของเซิร์ฟเวอร์สคริปต์ / แอพเท่านั้น

— deviDave

REST เป็นแนวทางสำหรับการออกแบบซีแมนทิกส์ของอินเทอร์เฟซ เทคโนโลยีพื้นฐานคือ HTTP ไม่ว่าอินเทอร์เฟซจะสงบหรือไม่ (แต่เลเยอร์อื่น ๆ เช่น XML-RPC หรือ SOAP นั้นไม่เกี่ยวข้องกับอินเตอร์เฟส RESTful) ดังนั้นคุณจึงใช้ httpget, httppost เดียวกันเสมอ แต่คุณจัดการกับความล้มเหลวของเครือข่ายแตกต่างกัน

— Jan Hudec

เพื่อเพิ่ม SMTP เป็นอินเตอร์เฟส RESTful แม้ว่ามันจะใช้คำกริยาที่แตกต่างจาก GET, PUT ฯลฯ และโปรโตคอลพื้นฐานที่แตกต่างกันแนวคิดก็เหมือนกัน - คุณส่งคำสั่งที่ใช้กริยา idempotent ไปยังเซิร์ฟเวอร์

— gbjbaanb

ไม่ใช่คำขอ REST ทั้งหมดที่เป็น idempotent ตัวอย่างเช่นการออก POST หลายครั้งจะส่งผลให้มีทรัพยากรใหม่มากมาย

— Gary Rowe

REST กับ RESTful และบริการเว็บ“ ปกติ” - เหมือนกันหรือไม่?