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

ฉันกำลังออกแบบเว็บเซอร์วิส RESTful โดยใช้ WebApi และสงสัยว่าการตอบสนอง HTTP และร่างกายการตอบสนองที่จะกลับมาเมื่อมีการปรับปรุง / สร้างวัตถุ ตัวอย่างเช่นฉันสามารถใช้วิธีการโพสต์เพื่อส่ง JSON บางส่วนไปยังบริการเว็บแล้วสร้างวัตถุ เป็นวิธีที่ดีที่สุดหรือไม่ที่จะตั้งค่าสถานะ HTTP เป็นสร้าง (201) หรือตกลง (200) และเพียงแค่ส่งคืนข้อความเช่น "เพิ่มพนักงานใหม่" หรือส่งคืนวัตถุที่ถูกส่งมาตั้งแต่แรก? เช่นเดียวกับวิธี PUT สถานะ HTTP ใดดีที่สุดที่จะใช้และฉันจำเป็นต้องส่งคืนวัตถุที่สร้างขึ้นหรือเพียงแค่ข้อความ พิจารณาข้อเท็จจริงที่ว่าผู้ใช้รู้ว่าวัตถุใดที่พวกเขากำลังพยายามสร้าง / อัปเดตอยู่ดี ความคิดใด ๆ ตัวอย่าง: เพิ่มพนักงานใหม่: POST /api/employee HTTP/1.1 Host: localhost:8000 Content-Type: application/json { "Employee": { "Name" : "Joe Bloggs", "Department" : "Finance" …

35 rest  http 

ในขณะที่ฉันเข้าใจว่า HATEOAS นั้นเกี่ยวกับการส่งลิงก์ตอบกลับแต่ละลิงก์พร้อมด้วยข้อมูลเกี่ยวกับสิ่งที่ต้องทำ ตัวอย่างง่ายๆอย่างหนึ่งสามารถพบได้ง่ายบนอินเทอร์เน็ต: ระบบธนาคารพร้อมกับทรัพยากรบัญชี ตัวอย่างแสดงการตอบสนองนี้หลังจากได้รับการร้องขอไปยังทรัพยากรบัญชี GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">100.00</balance> <link rel="deposit" href="/account/12345/deposit" /> <link rel="withdraw" href="/account/12345/withdraw" /> <link rel="transfer" href="/account/12345/transfer" /> <link rel="close" href="/account/12345/close" /> </account> ร่วมกับข้อมูลมีลิงค์บอกสิ่งที่สามารถทำได้ต่อไป หากยอดคงเหลือเป็นลบเรามี GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">-25.00</balance> <link …

35 rest  client-server  hateoas 

ฉันกำลังทำงานในโครงการที่เราพยายามใช้ทั้งการออกแบบที่ขับเคลื่อนด้วยโดเมนและ REST กับสถาปัตยกรรมที่มุ่งเน้นบริการ เราไม่กังวลเกี่ยวกับการปฏิบัติตาม REST 100% อาจเป็นการดีกว่าถ้าจะบอกว่าเรากำลังพยายามสร้าง HTTP API ที่เน้นการใช้ทรัพยากร (~ ระดับ 2ของแบบจำลองวุฒิภาวะ REST ของ Richardson) แต่เรากำลังพยายามที่จะอยู่ห่างจากการใช้ RPC-รูปแบบของการร้องขอ HTTP เช่นเราพยายามที่จะดำเนินการของเรา HTTP กริยาตามRFC2616มากกว่าที่จะใช้POSTในการทำIsPostalAddressValid(...)เช่น อย่างไรก็ตามการเน้นเรื่องนี้ดูเหมือนว่าจะเป็นค่าใช้จ่ายของความพยายามของเราที่จะใช้การออกแบบที่ขับเคลื่อนด้วยโดเมน มีเพียงGET, POST, PUT, DELETEและไม่กี่วิธีที่ไม่ค่อยได้ใช้อื่น ๆ ที่เรามีแนวโน้มที่จะสร้างบริการ cruddy และบริการ cruddy มีแนวโน้มที่จะมีรูปแบบโดเมนโรคโลหิตจาง POST: รับข้อมูลตรวจสอบความถูกต้องถ่ายโอนข้อมูลไปยังข้อมูล GET: ดึงข้อมูลกลับคืนมา ไม่มีตรรกะทางธุรกิจที่แท้จริงที่นั่น นอกจากนี้เรายังใช้ข้อความ (เหตุการณ์) ระหว่างบริการและดูเหมือนว่าตรรกะทางธุรกิจส่วนใหญ่จะสร้างขึ้นมา REST และ DDD มีความตึงเครียดในบางระดับหรือไม่? (หรือฉันเข้าใจผิดบางอย่างที่นี่เราอาจทำผิดอย่างอื่นหรือไม่) เป็นไปได้ไหมที่จะสร้างโมเดลโดเมนที่แข็งแกร่งในสถาปัตยกรรมเชิงบริการขณะที่หลีกเลี่ยงการโทร HTTP สไตล์ RPC?

34 rest  domain-driven-design  domain-model 

เรามี URL ในรูปแบบดังต่อไปนี้ / อินสแตนซ์ / {instanceType} / {} InstanceID คุณสามารถเรียกมันได้ด้วยวิธี HTTP มาตรฐาน: POST, GET, DELETE, PUT อย่างไรก็ตามมีการกระทำอีกสองสามอย่างที่เราดำเนินการเช่น "บันทึกเป็นแบบร่าง" หรือ "Curate" เราคิดว่าเราสามารถใช้วิธี HTTP แบบกำหนดเองเช่น: DRAFT, VALIDATE, CURATE ฉันคิดว่านี่เป็นสิ่งที่ยอมรับได้เพราะมาตรฐานบอกว่า "ชุดวิธีการทั่วไปสำหรับ HTTP / 1.1 ถูกกำหนดไว้ด้านล่างแม้ว่าชุดนี้สามารถขยายได้ แต่วิธีการเพิ่มเติมไม่สามารถสันนิษฐานได้ว่าจะใช้ความหมายเดียวกันสำหรับไคลเอนต์และเซิร์ฟเวอร์แยกกัน" และเครื่องมือเช่น WebDav สร้างส่วนขยายของตัวเอง มีปัญหาที่บางคนใช้กับวิธีการที่กำหนดเองหรือไม่? ฉันกำลังคิดถึงพร็อกซีเซิร์ฟเวอร์และไฟร์วอลล์ แต่ยินดีต้อนรับประเด็นอื่น ๆ ฉันควรอยู่อย่างปลอดภัยและมีพารามิเตอร์ URL เช่น action = validate | curate | …

34 rest  http 

มีมาตรฐานบางอย่างเกี่ยวกับการตอบกลับ HTTP API หรือไม่ หลังจากอ่านหัวข้อสนทนานี้ฉันเริ่มสงสัย เรากำลังพัฒนา HTTP JSON API สาธารณะของเราในที่ทำงานของฉันและเราจะไม่ส่งคืนสิ่งใดเมื่อไม่จำเป็นอย่างเคร่งครัด (เช่น PUT to / resource / {id} เท่านั้นส่งคืน 200 เมื่อตกลงหรือรหัส 4XX หรือ 5XX ที่เกี่ยวข้อง แต่ไม่ ร่างกาย JSON) เราควรคืนค่าตัวแบบทั่วไป{"success":true}เช่นที่พวกเขาพูดคุยเกี่ยวกับลิงก์ข้างต้นหรือไม่มันก็โอเคที่จะคืนค่าส่วน "โมฆะ" และจัดการทุกอย่างด้วยรหัสตอบกลับ http?

33 rest  api-design  http 

หลังจากดูการพูดคุยนี้ใน REST แล้ว Reuse and Serendipityโดย Steve Vinoski ฉันสงสัยว่ามีกรณีธุรกิจในโครงการกรีนฟิลด์สำหรับ (XML-) การตั้งค่า RPC-ish ที่ REST ไม่สามารถแก้ไขได้ในทางที่ดีขึ้น ปัญหา RPC สองสามอย่างที่เขากล่าวถึง: มุ่งเน้นที่ภาษา (จัดระบบให้เหมาะสมกับภาษาไม่ใช่วิธีอื่น ๆ ) "ทำให้ดูเป็นท้องถิ่น" (และรับมือกับความล้มเหลวและความหน่วงแฝงเป็นข้อยกเว้นมากกว่ากฎ) ตั้งใจที่จะเป็นภาษาที่เป็นอิสระ แต่ยังคงมี "การเรียกใช้ฟังก์ชัน" ข้ามภาษาเป็นส่วนผสมหลัก IDLสำเร็จรูป ภาพลวงตาของความปลอดภัยประเภท และอีกไม่กี่ ... เพียงเพิ่มบทละครลงเล็กน้อยผลการค้นหาทันใจของ Google สำหรับ RPC และ REST:

33 web-services  rest  use-case  rpc 

ในอดีตที่ผ่านมาทั้งสอง บริษัท ฉันเคยอยู่ที่ REST API มีอยู่สำหรับการสืบค้นข้อมูลผ่านเว็บแอป กล่าวคือ แทนที่จะมีเว็บแอปทำ SQL โดยตรงจะเรียกใช้ REST API และนั่นคือ SQL และส่งคืนผลลัพธ์ คำถามของฉันคือ ... ทำไมจึงทำเช่นนี้? ถ้ามันจะถูกเปิดเผยต่อบุคคลที่สามฉันสามารถเข้าใจได้ ดีกว่าที่จะเปิดเผย REST API ที่ จำกัด กว่า DB แบบเต็ม แต่ในทั้งสอง บริษัท นี้ไม่ได้เป็นเช่นนั้น มีคนแนะนำฉันว่า REST API เหล่านี้ทำให้การสลับระหว่าง DBMS ง่ายขึ้น แต่นั่นไม่ใช่จุดของ abstraction layer ของฐานข้อมูล (DBAL) ใช่ไหม บางทีคุณอาจใช้ ORM เป็น DBAL ของคุณหรือคุณอาจเขียน SQL ดิบและให้ DBAL …

32 database  web-applications  rest  web-api 

สมมติว่าฉันมี REST API ที่ใช้ในการตั้งค่า / รีเซ็ตรหัสผ่าน สมมติว่าวิธีนี้ใช้ได้กับการเชื่อมต่อ HTTPS มีเหตุผลที่ดีที่จะไม่ใส่รหัสผ่านนั้นในเส้นทางการโทรหรือเปล่าสมมุติว่าฉันจะเข้ารหัสใน BASE64 ตัวอย่างจะรีเซ็ตรหัสผ่านดังนี้: http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD ฉันเข้าใจว่า BASE64 ไม่ใช่การเข้ารหัส แต่ฉันเพียงต้องการปกป้องรหัสผ่านเพื่อท่องในกรณีนี้

31 rest  passwords 

เท่าที่ฉันเห็นการบริโภค SOAP ต้องใช้ SOAP stack ดังนั้นจึงยากสำหรับลูกค้าของคุณที่จะใช้เช่นพวกเขาต้องการให้แน่ใจว่าพวกเขามี SOAP stack ในสถานที่ที่จัดรูปแบบข้อมูล POST และส่วนหัวได้อย่างถูกต้อง โครงสร้างข้อมูลในขณะที่ REST คุณเพียงแค่ร้องขอ HTTP GET พร้อมอาร์กิวเมนต์ในสตริงการสืบค้นและรับข้อความที่ฉันคิดว่าน่าจะเป็น XML กลับมา ดังนั้นค่าใช้จ่ายพิเศษ / ความซับซ้อนของ SOAP ให้อะไรคุณเมื่อไหร่ที่คุณต้องการและเมื่อไหร่ที่คุณและคุณควรจะทำโดยไม่ต้องทำ?

30 web-services  rest  soap 

ฉันกำลังสร้าง REST API ซึ่งผู้ใช้หลายคนที่มีบทบาทที่แตกต่างกันจะสามารถเข้าถึงทรัพยากรที่มีอยู่ เพื่อให้ขอบเขตง่ายขึ้นขอโดเมน "นักเรียน / ครู / ชั้นเรียน": GET /students เป็นทรัพยากรที่จะเข้าถึง ผู้ใช้อาจมีบทบาทเช่นนักเรียนและ / หรืออาจารย์ นักเรียนจะสามารถเข้าถึงนักเรียนของชั้นเรียนของพวกเขาเท่านั้น ครูจะสามารถเข้าถึงนักเรียนของชั้นเรียนที่พวกเขาสอน การใช้งานบางอย่างอาจเป็นนักเรียนและสอนชั้นเรียนอื่น ๆ ด้วย พวกเขาจะต้องสามารถเข้าถึงนักเรียนของชั้นเรียนของพวกเขาและนักเรียนของชั้นเรียนที่พวกเขาสอน นึกคิดฉันต้องการที่จะใช้สิ่งนี้เป็นสองฟังก์ชั่น - หนึ่งต่อบทบาทและจากนั้น "สหภาพ" ถ้าผู้ใช้มีหลายบทบาท คำถามของฉันคือฉันควรใช้รูปแบบใดในการดำเนินการนี้ อย่างผิวเผิน ฉันควรแยก API ต่อบทบาทของฉันหรือไม่ GET /teacher/studentsและGET /student/studentsดูเหมือนจะไม่ถูกต้องสำหรับฉัน เก็บทุกอย่างฉันเป็นแหล่งข้อมูลเดียว (แนะนำ) ภายใน ควรนำไปใช้ภายในอย่างไร ทุกวิธีควรเริ่มต้นด้วยสวิตช์ขนาดใหญ่ / ต่อบทบาทหรือไม่ ฉันควรใช้ที่เก็บต่อบทบาทหรือไม่ มีรูปแบบการออกแบบที่จะช่วยฉันในการบรรลุเป้าหมายนี้หรือไม่? ตามความเห็นด้านข้าง: ฉันใช้ASP.NET Web APIและEntity Framework 6แต่จริงๆแล้วมันไม่สำคัญสำหรับการนำแนวคิดไปใช้

27 design-patterns  programming-practices  rest  web-api 

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

27 web-applications  rest  standards 

มันเป็นแบบแผนที่ค่อนข้างกำหนดไว้ว่าอย่างน้อยชื่อตารางฐานข้อมูลใน SQL ควรเป็นแบบเอกพจน์ SELECT * FROM user;ดูคำถามและการอภิปรายนี้ นอกจากนี้ยังมีการประชุมที่ค่อนข้างดีที่ชื่อทรัพยากร RESTful API ควรเป็นพหูพจน์ GET /users/123และPOST /usersดูคนนี้ ใน API ที่ได้รับการสนับสนุนฐานข้อมูลที่ง่ายที่สุดชื่อของทรัพยากรใน URL จะเป็นตารางและองค์ประกอบข้อมูลใน URL และหน่วยงานร้องขอ / ตอบสนองจะจับคู่กับคอลัมน์ในฐานข้อมูลโดยตรง ตามแนวคิดแล้วฉันไม่เห็นความแตกต่างระหว่างการทำงานกับข้อมูลผ่าน API เชิงทฤษฎีนี้กับการทำงานบน SQL โดยตรง และด้วยเหตุนี้ความแตกต่างในการตั้งชื่อข้อตกลงระหว่างuserและusersไม่สมเหตุสมผลกับฉัน ความแตกต่างในการทำให้เป็นพหูพจน์เป็นอย่างไรเมื่อแนวคิด REST API และ SQL กำลังทำสิ่งเดียวกัน

27 rest  api  sql  conventions  naming-standards 

เรามีเฟรมเวิร์กบริการเว็บ asp.net MVC สำหรับการให้บริการ xml / json สำหรับผู้คนรับคำขอ แต่กำลังพยายามหาวิธีที่ดีที่สุด (รวดเร็วง่ายและไม่สำคัญสำหรับผู้ใช้ที่เข้ารหัสด้วยจาวาสคริปต์หรือภาษา OO) เพื่อรับรองความถูกต้องของผู้ใช้ ไม่ใช่ว่าข้อมูลของเรามีความละเอียดอ่อนหรืออะไรเราเพียงต้องการให้ผู้ใช้ลงทะเบียนเพื่อให้เราสามารถมีที่อยู่อีเมลของพวกเขาเพื่อแจ้งให้ทราบถึงการเปลี่ยนแปลงและติดตามการใช้งาน ในความพยายามครั้งก่อนของเราเรามีชื่อผู้ใช้ใน URI และจะทำให้แน่ใจว่าชื่อผู้ใช้นั้นมีอยู่และเพิ่มตารางฐานข้อมูลด้วยการใช้งาน นี่เป็นขั้นพื้นฐานสุด ๆ แต่เราจะสังเกตเห็นคนที่ใช้การสาธิตเป็นชื่อผู้ใช้ ฯลฯ ดังนั้นเราจึงต้องการให้มันซับซ้อนขึ้นเล็กน้อย มีเทคนิคการรับรองความถูกต้องอะไรบ้าง สิ่งที่ผู้เล่นสำคัญใช้ / ทำ

26 security  api  web  services  rest 

ฉันกำลังพิจารณาที่จะย้าย REST API แบบเสาหินไปยังสถาปัตยกรรม microservice และฉันสับสนเล็กน้อยเกี่ยวกับที่เก็บข้อมูล ตามที่ฉันเห็นประโยชน์บางประการของ microservices คือ: ปรับขนาดได้ในแนวนอน - ฉันสามารถเรียกใช้สำเนาบริการซ้ำซ้อนหลายชุดเพื่อจัดการกับโหลดและ / หรือเซิร์ฟเวอร์หยุดทำงาน การเชื่อมโยงอย่างหลวม - ฉันสามารถเปลี่ยนการใช้งานภายในของไมโครไซต์โดยไม่ต้องเปลี่ยนไมโครซอฟท์และฉันสามารถปรับใช้และเปลี่ยนแปลงได้อย่างอิสระ ... ปัญหาของฉันอยู่ที่การจัดเก็บข้อมูล เท่าที่ฉันเห็นมันมีหลายตัวเลือก: บริการฐานข้อมูลเดียวที่ใช้ร่วมกันโดย microservices ทั้งหมด - นี่ดูเหมือนจะขจัดข้อได้เปรียบของการมีเพศสัมพันธ์แบบหลวม ๆ อย่างสมบูรณ์ อินสแตนซ์ฐานข้อมูลที่ติดตั้งในเครื่องบนไมโครไซต์แต่ละบริการ - ฉันไม่เห็นวิธีการปรับขนาดแนวนอนดังนั้นฉันไม่คิดว่ามันจะเป็นตัวเลือก microservice แต่ละตัวมีบริการฐานข้อมูลของตัวเอง - ซึ่งเป็นวิธีที่มีแนวโน้มมากที่สุดเนื่องจากจะรักษาประโยชน์ของข้อต่อหลวมและการขยายตามแนวนอน (โดยใช้สำเนาฐานข้อมูลที่ซ้ำซ้อนและ / หรือทำให้เกิดปัญหาหลายอย่าง) สำหรับฉันตัวเลือกที่สามน่าจะเป็นตัวเลือกเดียว แต่ดูเหมือนว่าฉันจะมีน้ำหนักมากอย่างไม่น่าเชื่อและเป็นวิธีแก้ปัญหาที่มีการปรับแก้มากเกินไป ถ้าฉันเข้าใจถูกต้องแล้วสำหรับแอปพลิเคชันธรรมดาที่มี 4-5 microservices ฉันต้องใช้เซิร์ฟเวอร์ 16-20 - สองอินสแตนซ์ microservice จริงสองต่อ microservice (ในกรณีที่เซิร์ฟเวอร์ล้มเหลวและสำหรับการปรับใช้โดยไม่ต้องหยุดทำงาน) …

25 architecture  rest  api-design  microservices 

ฉันกำลังทำงานในโครงการแอพ iOS ใหม่ทางมือถือ การเปลี่ยนแปลงสถาปัตยกรรมบางอย่างกำลังเกิดขึ้นและปรากฎว่าเราจะต้องพึ่งพา API ส่วนตัวที่สร้างขึ้นเองซึ่งจะถูกใช้โดยแอพที่เรากำลังสร้างและลูกค้ารายอื่นเช่นเว็บไซต์ API ที่ถูกออกแบบตามสไตล์ Rest ของการดำเนินการ URI และ CRUD ที่เน้นทรัพยากรเป็นศูนย์กลางจับคู่กับกริยา HTTP สิ่งที่ชอบ: GET www.example.com/books DELETE www.example.com/books/482094 POST www.example.com/users/6793 ปัญหาคือว่ารูปแบบนี้มักจะนำไปสู่ความต้องการให้ไคลเอนต์มือถือทำการร้องขอมากมายสำหรับการโหลดหน้าจอแอปเดียวหรือจัดการการกระทำ UI ของผู้ใช้คนเดียว สิ่งนี้นำไปสู่แอปที่อยู่ในโหมดโหลดเป็นเวลา 8 วินาทีจนกว่าจะมีทุกอย่างที่จำเป็น แอพที่ช้าและไม่ตอบสนอง ไคลเอนต์มือถือมีข้อ จำกัด ที่ร้ายแรงเมื่อพูดถึงการเชื่อมต่อดังนั้นเราควรปฏิบัติตามกฎดังกล่าว: 1 หน้าจอ == 1 การเรียก API 1 บันทึก == 1 การเรียก API มีหลายสถานการณ์ที่สิ่งนี้ทำให้คุณมีหลักสูตรการชนด้วยหลักการออกแบบ REST เช่น: สมมติว่าแอปของคุณออฟไลน์อยู่หนึ่งวันและคุณจำเป็นต้องซิงค์กับฐานข้อมูลแบ็กเอนด์สี่ตารางและคุณต้องการโทรศัพท์เช่น www.example.com/sync_everything?since=2015-07-24 สมมติว่ามีหน้าจอที่ผู้ใช้สามารถแก้ไขวัตถุของเขาได้หลายอย่างเช่นการทำเครื่องหมายในรายการสิ่งที่ต้องทำ …

25 rest  api  ios  mobile