คำถามติดแท็ก rest

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

13 api  rest 

สมมติว่าฉันมีเว็บแอปพลิเคชัน JavaScript ซึ่งใช้ RESTful API สำหรับข้อมูลทั้งหมด สมมติว่าแอปพลิเคชันนี้มีฟอร์มข้อมูลและสมมติว่าฉันกำลังแก้ไขระเบียนที่ / product / 12345 เมื่อสร้างแบบฟอร์มฉันขอ RESTful ให้กับ / product / 12345 และรับข้อมูล JSON: { "id": 12345, "name": "Some Product", "active": true, "sales_user_id": 27 } ดังนั้นแบบฟอร์มของฉันอาจมีรายการแบบเลื่อนลงสำหรับการเลือกพนักงานขาย ฉันต้องการเติมรายการนี้ ข้อมูลควรมาจากไหน วิธีที่พบมากที่สุดคืออะไร มันจะสมเหตุสมผลไหมที่จะทำให้มันเป็นส่วนหนึ่งของการตอบสนองคำขอ / product / 12345 { "id": 12345, "name": "Some Product", "active": true, "sales_user_id": 27, …

13 api  rest  forms 

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

13 web-services  rest 

ฉันอ้างถึงบทความที่ยอดเยี่ยมhttp://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ซึ่งพูดถึง amazon เช่นความปลอดภัยสำหรับบริการเว็บ อย่างไรก็ตามฉันถูกถามคำถามในทีมว่าทำไมเราถึงต้องการถ้าเราใช้ HTTPS อยู่แล้ว ฉันไม่สามารถตอบได้เพราะจริง ๆ แล้วดูเหมือนว่าฉันจะพูดถูก มีสถานที่ให้บริการ REST ที่ HTTPS อาจไม่ทำงานหรือไม่ ชอบเว็บไซต์บุคคลที่สามหรือไม่ หากใครมีประสบการณ์ในการรักษาความปลอดภัยบริการทางเว็บผ่านทางเว็บสาธารณะกรุณาเล่าถึงประสบการณ์ของคุณ ขอบคุณล่วงหน้า. แก้ไข: เพื่อชี้แจงฉันไม่ได้พูดถึงการตรวจสอบผู้ใช้ แต่การตรวจสอบลูกค้าเพิ่มเติม การพิสูจน์ตัวตนผู้ใช้สามารถถือว่าเป็นข้อความธรรมดาผ่าน HTTPS + REST ความกังวลของฉันคือสิ่งนี้ยังช่วยให้ทุกคนสามารถใช้บริการเว็บโดยที่ลูกค้าของฉันไม่สามารถเข้าถึงได้เนื่องจากทุกอย่างเป็นข้อความธรรมดาแม้ผ่าน HTTPS จุดสิ้นสุดไคลเอ็นต์ยังคงสามารถใช้บริการเว็บของฉันได้โดยไม่ต้องมีแอปพลิเคชันไคลเอนต์

13 rest 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันสนใจที่จะพัฒนาเว็บไซต์ขนาดใหญ่ที่ผู้ใช้งานเขียนด้วยภาษาจาวา สำหรับการออกแบบฉันคิดว่าการพัฒนาบริการแบบแยกส่วนอิสระที่สามารถทำหน้าที่เป็นผู้ให้บริการข้อมูลกับเว็บแอปพลิเคชันหลักของฉัน สำหรับการเขียนบริการแบบแยกส่วน (ผู้ให้บริการข้อมูล) ฉันสามารถใช้ประโยชน์จากเฟรมเวิร์กที่มีอยู่เช่น Spring และพัฒนาบริการเหล่านี้ตามรูปแบบการออกแบบ RESTful และเปิดเผยทรัพยากรผ่าน HTTP ด้วยรูปแบบข้อความเช่น JSON ... หรือฉันสามารถใช้ประโยชน์จากเครือข่ายที่มีอยู่ เฟรมเวิร์กเช่น Netty ( http://netty.io/ ) และรูปแบบการทำให้เป็นอนุกรมเช่น Protobufs ( https://developers.google.com/protocol-buffers/docs/overview ) และพัฒนาเซิร์ฟเวอร์ TCP ที่ส่งกลับมาแบบอนุกรม น้ำหนักบรรทุก เมื่อใดที่คุณควรเลือกรายการอื่น จะมีประโยชน์ใด ๆ จากการใช้รูปแบบการทำให้เป็นอันดับเช่น Protobufs และการส่งกระแสข้อมูลของไบต์ผ่านสาย จะมีค่าใช้จ่ายในการใช้ JSON หรือไม่ มีค่าใช้จ่ายเท่าไรในการใช้ TCP / IP และ HTTP …

13 java  rest  http  serialization  tcp 

ฉันทำการค้นคว้าเกี่ยวกับการออกแบบบริการเว็บสงบและฉันได้มาถึงสิ่งที่ฉันคิดว่าเป็นจุดตัดสินใจที่สำคัญดังนั้นฉันคิดว่าฉันจะเสนอมันต่อชุมชนเพื่อรับคำแนะนำ เพื่อให้สอดคล้องกับหลักการของสถาปัตยกรรม RESTful ฉันต้องการนำเสนอ API ที่สามารถค้นพบได้ดังนั้นฉันจะสนับสนุนคำกริยา HTTP ต่างๆอย่างเต็มที่เท่าที่จะทำได้ ความยากของฉันมาพร้อมกับตัวเลือกในการแสดงทรัพยากรเหล่านั้น คุณเห็นไหมว่ามันจะเป็นเรื่องง่ายสำหรับผมที่จะสร้าง API ของตัวเองซึ่งจะครอบคลุมถึงการนำเสนอผลการค้นหาและการเชื่อมโยงไปยังแหล่งข้อมูลอื่น ๆ ฉันได้อ่านเกี่ยวกับ Atom Publishing Protocol ( RFC 5023 ) และวิธีการที่ODataส่งเสริมการใช้งาน แต่ดูเหมือนว่าจะเพิ่มระดับการเพิ่มความเป็นนามธรรมให้กับ API ที่ค่อนข้างง่าย (ปัจจุบัน) ดังนั้นคำถามของฉันคือนักพัฒนาควรเลือก AtomPub เป็นตัวเลือกในการแสดงของพวกเขาเมื่อใด? และถ้าไม่ใช่แนวทางที่แนะนำในปัจจุบันคืออะไร?

13 web-services  rest  api-design 

ฉันสลับไปมา ~ 5 ครั้งแล้ว ปลายทาง REST นี้ที่/api/tags/จะใช้ภายใน (ไม่มีลูกค้าภายนอก) ฉันเป็นคนเดียวที่ทำงานกับมัน ฉันกำลังตัดสินใจระหว่างตัวแทนสองคนนี้: แบน { "types":[ { "id":1, "text":"Utility" }, { "id":7, "text":"Lease Terms" }, ], "tags":[ { "id":8, "text":"Water", "type":1 }, { "id":9, "text":"Electricity", "type":1 }, { "id":5, "text":"Minimum 12 month lease", "type":7 }, { "id":17, "text":"lease negotiable/flexible", "type":7 }, ] } …

12 rest  api-design  json 

ฉันกำลังออกแบบ RESTful API และประสบกับปัญหาชื่อเรื่องซึ่งได้รับการปรับปรุงใหม่เพื่อความชัดเจน: ฉันควรจะล้มเหลวอย่างรวดเร็วหากลูกค้าส่งพารามิเตอร์ที่ไม่รู้จัก? ตัวอย่างเช่น, http://example.com/api/foo?bar=true&paula=bean ในด้านบนbarเป็นพารามิเตอร์ที่ถูกต้อง แต่paulaไม่ได้ระบุไว้โดย API ฉันควร เตือนให้ลูกค้าทราบถึงข้อผิดพลาด ล้มเหลวอย่างรวดเร็ว ไม่ต้องสนใจมัน ถ้าฉันเตือนไคลเอนต์ฉันสามารถออกคำเตือนสำหรับพารามิเตอร์แรกเท่านั้นเนื่องจากพวกเขาสามารถส่งได้ใกล้จำนวนไม่สิ้นสุดและเซิร์ฟเวอร์น่าจะมีสิ่งที่ต้องทำดีกว่า ในทำนองเดียวกันเมื่อล้มเหลวมันจะระบุพารามิเตอร์ที่ไม่ถูกต้องครั้งแรกเป็นปัญหาเท่านั้น ฉันชอบความล้มเหลวมากกว่าการออกคำเตือนเพื่อบังคับให้โปรแกรมเมอร์ดำเนินการเนื่องจากอาจเพิกเฉยต่อปัญหาและทำให้สิ้นเปลืองทรัพยากรหรือทำให้การขนส่งสินค้าเกิดปัญหาโดยไม่ตั้งใจ การไม่ทำสิ่งใดที่เลวร้ายยิ่งไปกว่านั้นในแง่นั้น ข้อโต้แย้งของฉันสมเหตุสมผลหรือไม่ มีวิธีปฏิบัติที่เป็นที่ยอมรับในเรื่องดังกล่าวหรือไม่?

12 rest  api-design 

เรากำลังพัฒนา REST API ซึ่งส่วนอื่น ๆ จะถูกใช้โดยส่วนหน้า HTML5 ผ่านทางจาวาสคริปต์ แอปพลิเคชันมีไว้สำหรับใช้ภายในองค์กรและมักจะมีผู้ใช้ประมาณ 300 คน แต่เราต้องการที่จะขยายผู้ใช้ให้ได้มากถึง 1,000 คน โดยทั่วไปแล้วการเชื่อมต่อกับ API จะทำภายใน LAN ดังนั้นคุณภาพและเวลาแฝงของการเชื่อมต่อจะดีแม้ว่าจะไม่ได้ยกเว้นการใช้งานผ่านอินเทอร์เน็ตเป็นครั้งคราวซึ่งการเชื่อมต่ออาจช้าลงและมีความล่าช้ามากขึ้นผ่านทาง 3G / 4G ตัวเลือกสองตัวที่เราคิดคือ: ส่วนหน้าจะทำการเรียกใช้แบบอะซิงโครนัสพร้อมกันหลายครั้งเพื่อโหลดส่วนประกอบต่าง ๆ ของอินเทอร์เฟซ จุดเด่น: เรียบง่าย จุดด้อย: การเชื่อมต่อกับเซิร์ฟเวอร์มากขึ้น ตัวควบคุมของส่วนหน้าจะทำการเรียก API ผ่านครั้งเดียวเป็นพารามิเตอร์ที่ต้องดึงข้อมูลวัตถุ ข้อดี: มีการเชื่อมต่อกับเซิร์ฟเวอร์เพียงครั้งเดียวแม้ว่าเซิร์ฟเวอร์จะทำการเชื่อมต่อกับฐานข้อมูลหลายครั้ง ข้อด้อย: ต้องใช้กลไกทั้งในส่วนหน้าและ API มันซับซ้อนการออกแบบ คำอธิบายเพิ่มเติม: จะมีทรัพยากรที่แตกต่างกัน ... / ผลิตภัณฑ์ ... / ที่ตั้ง ฯลฯ ทรัพยากรเหล่านี้สามารถดึงข้อมูลได้เพียงอย่างเดียว แต่จะมีทรัพยากรที่เป็นนามธรรม …

12 rest  api  ajax 

ฉันเข้าใจว่าเมื่อตั้งชื่อ RESTful URI เป็นที่ยอมรับกันโดยทั่วไปในการใช้คำพหูพจน์เพื่อแสดงชุดของทรัพยากร ฉันอยากรู้ว่าอาร์กิวเมนต์สำหรับการใช้คำนามเอกพจน์แทน

12 api  rest  uri 

ฉันไม่เคยสร้าง RESTful API มาก่อนและฉันสงสัยว่ามันควรแยกออกจากกันอย่างไร ตัวอย่างเช่นสมมติว่าฉันมีลูกค้าที่มีชื่อที่อยู่หมายเลขโทรศัพท์ที่อยู่อีเมลภาษา ฯลฯ มันสมเหตุสมผลหรือไม่ที่มีวิธีอัปเดตแต่ละฟิลด์ (อัปเดตที่อยู่อัปเดตที่อยู่อีเมล ฯลฯ ) หรือควรจะมีการอัปเดตเดียวสำหรับลูกค้าทั้งหมดและแต่ละฟิลด์เป็นฟิลด์เสริมหรือไม่

12 api  rest 

ฉันอยู่ในขั้นตอนการออกแบบ HTTP API หวังว่าจะทำให้ RESTful ที่สุดเท่าที่จะทำได้ มีการกระทำบางอย่างที่ฟังก์ชันการทำงานกระจายไปทั่วทรัพยากรบางอย่างและบางครั้งจำเป็นต้องเลิกทำ ฉันคิดกับตัวเองเสียงนี้ดูเหมือนรูปแบบคำสั่ง แต่ฉันจะสร้างแบบจำลองเป็นทรัพยากรได้อย่างไร ฉันจะแนะนำทรัพยากรใหม่ชื่อ XXAction เช่น DepositAction ซึ่งจะถูกสร้างขึ้นผ่านบางสิ่งเช่นนี้ POST /card/{card-id}/account/{account-id}/Deposit AmountToDeposit=100, different parameters... สิ่งนี้จะสร้าง DepositAction ใหม่และเปิดใช้งานวิธีการ Do / Execute ในกรณีนี้การส่งคืนสถานะ HTTP ที่สร้าง 201 หมายถึงการดำเนินการถูกดำเนินการสำเร็จ หลังจากนั้นหากลูกค้าต้องการดูรายละเอียดการกระทำที่เขาสามารถทำได้ GET /action/{action-id} ควรปิดกั้นการอัปเดต / วางเพราะฉันไม่เกี่ยวข้องที่นี่ และเพื่อเลิกทำการกระทำฉันคิดถึงการใช้ DELETE /action/{action-id} ซึ่งจริงๆแล้วจะเรียกวิธีการเลิกทำของวัตถุที่เกี่ยวข้องและเปลี่ยนสถานะเป็น สมมติว่าฉันมีความสุขกับสิ่งเดียวที่ต้องเลิกทำฉันไม่จำเป็นต้องทำซ้ำ วิธีนี้ใช้ได้หรือไม่ มีข้อผิดพลาดใด ๆ เหตุผลที่จะไม่ใช้มัน? สิ่งนี้เป็นที่เข้าใจจาก POV ของลูกค้าหรือไม่

12 design-patterns  api  rest  api-design  http 

ฉันกำลังหาแอพพลิเคชั่นแบบกระจายซึ่งจะประกอบด้วยบริการ REST และไคลเอนต์ที่หลากหลาย (Silverlight, iOS, Windows Phone 7 และอื่น ๆ ) ฉันพร้อมที่จะตัดสินใจว่าจะใช้บริการ REST โดยใช้ WCF Data Services (OData) แต่ตอนนี้ MVC 4 Web API ทำให้ฉันตั้งคำถามกับการตัดสินใจว่า สิ่งที่ฉันชอบเกี่ยวกับ OData คือความสามารถในการสืบค้น URI และไฮเปอร์มีเดียที่คุณได้รับฟรี สิ่งที่ฉันไม่ชอบคือความฟุ่มเฟื่อยของอัตราการโหลด OData; ตัวละครที่ไม่จำเป็นจำนวนมากเดินผ่านเส้นลวด สิ่งที่ฉันชอบเกี่ยวกับ Web API คือ payloads มีความกระชับมากกว่าและมีความสามารถในการสอบถาม URI ของ OData แต่ดูเหมือนว่าขาดไฮเปอร์สื่อ (นอกกรอบอย่างน้อย) เจ้านายของฉันกำลังผลักดันเว็บ API เพราะ "พลังที่ Microsoft สนับสนุนอยู่และ OData …

12 rest  asp.net-mvc-4 

มันเกินความเป็นวิศวกรรมหรือไม่ถ้าฉันเพิ่มการป้องกันการกระทำผิดโดยเจตนาของผู้ใช้ (เพื่อกล่าวอย่างอ่อนโยน) หากความเสียหายที่ผู้ใช้สามารถได้รับนั้นไม่เกี่ยวข้องกับรหัสของฉันหรือไม่? เพื่อชี้แจงฉันกำลังเปิดเผยบริการ JSON RESTful แบบนี้: GET /items - to retrieve list of user's items PUT /items/id - to modify an item POST /items - to add a new item บริการนี้ไม่ได้มีไว้สำหรับใช้กับเบราว์เซอร์ แต่มาจากแอปพลิเคชันบุคคลที่สามซึ่งควบคุมโดยผู้ใช้ (เช่นแอพโทรศัพท์แอพเดสก์ท็อป ฯลฯ ) นอกจากนี้บริการควรไม่มีสถานะ (เช่นเซสชันน้อย) การรับรองความถูกต้องจะทำกับการตรวจสอบขั้นพื้นฐานผ่าน SSL ฉันกำลังพูดถึงพฤติกรรม "อันตราย" ที่เป็นไปได้เช่นนี้: ผู้ใช้ป้อน URL ของ GET ในเบราว์เซอร์ (ไม่มีเหตุผลยกเว้น ... …

12 rest  authentication 

ฉันกำลังตั้งค่าบริการเว็บสงบใหม่และฉันต้องการให้แบบจำลองการควบคุมการเข้าถึงตามบทบาท ฉันต้องสร้างสถาปัตยกรรมที่อนุญาตให้ผู้ใช้ระบุชื่อผู้ใช้และรหัสผ่านเพื่อเข้าถึงบริการและ จำกัด วิธีการใช้บริการ (บริการใดบ้างที่พวกเขาสามารถใช้อ่าน vs อ่าน / เขียน ฯลฯ ) ตามบทบาท มอบหมายให้กับผู้ใช้นั้น ฉันได้ดูคำถามอื่น ๆ และพบสิ่งที่ฉันต้องการ ตัวอย่างเช่นมีการอภิปรายที่ดีหลายประการเกี่ยวกับวิธีการจัดการข้อมูลประจำตัวที่ผ่านการบริการที่ REST พักผ่อนสบายตลอดการตรวจสอบ , การปฏิบัติที่ดีที่สุด นอกจากนี้ยังมีตัวชี้ที่ยอดเยี่ยมเกี่ยวกับสิ่งที่โปรแกรมเมอร์ควรรู้เมื่อสร้างเว็บไซต์ ( สิ่งที่นักพัฒนาทุกคนควรรู้ก่อนสร้างเว็บไซต์สาธารณะ ) แต่ฉันไม่สามารถค้นหาบทความบทความหนังสือเกี่ยวกับแนวปฏิบัติและรูปแบบที่ดีสำหรับสถาปัตยกรรมซอฟต์แวร์ที่ใช้โซลูชันเหล่านี้ โดยเฉพาะ: ควรจัดเก็บรายละเอียดผู้ใช้และสิทธิ์การเข้าถึงอย่างไร (ตัวแบบข้อมูล, สถานที่, รูปแบบ) รูปแบบการออกแบบที่ดีสำหรับการแสดงและติดตามสิ่งเหล่านี้ในเซิร์ฟเวอร์มีอะไรบ้าง (เซสชันในหน่วยความจำการค้นหาฐานข้อมูลในแต่ละครั้ง ฯลฯ ) อะไรคือรูปแบบที่ดีสำหรับการจับคู่สิทธิเหล่านี้กับบริการในวิธีที่ปลอดภัยในรหัสฐาน ตัวเลือกสถาปัตยกรรมใดบ้างที่สามารถช่วยให้ระบบปลอดภัยและเชื่อถือได้มากขึ้น ผู้เรียนมีบทเรียนอะไรบ้างจากสนามเพลาะ? ฉันกำลังมองหารูปแบบการออกแบบและคำแนะนำสำหรับสถาปัตยกรรมซอฟต์แวร์นอกเทคโนโลยีเฉพาะใด ๆ (หากเทคโนโลยีมีความสำคัญฉันกำลังวางแผนที่จะใช้สิ่งนี้โดยใช้ python, twisted, และฐานข้อมูล postgresql)

12 web-development  design-patterns  security  web-services  rest