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

ในขณะที่สร้างRESTful APIฉันควรใช้ HTTP Verbs บน URL เดียวกัน (เมื่อเป็นไปได้) หรือฉันควรสร้าง URL เฉพาะสำหรับแต่ละการกระทำ ตัวอย่างเช่น: GET /items # Read all items GET /items/:id # Read one item POST /items # Create a new item PUT /items/:id # Update one item DELETE /items/:id # Delete one item หรือด้วย URL เฉพาะเช่น: GET /items # Read …

25 rest  api-design  web-api 

ในโครงการปัจจุบันของฉันฉันรับผิดชอบการใช้งานบริการที่เกี่ยวข้องกับการใช้ RESTful APIs ที่สร้างขึ้นใหม่ซึ่งบันทึกไว้ว่ารองรับ JSON เท่านั้น ลูกค้าทำการร้องขออย่างต่อเนื่องโดยมีส่วนหัวการยอมรับของ 'application / json' และประเภทเนื้อหาของ 'application / json' อย่างไรก็ตามปลายทางบางจุดส่งการตอบกลับด้วย HTML ชนิดเนื้อหาหรือแม้แต่เนื้อหา HTML สำหรับฉันนี่เป็นแนวทางที่ผิดอย่างชัดเจนและไม่สามารถพิสูจน์ได้ ตลอดโครงการนี้มีการใช้วิธีปฏิบัติเดียวกันนี้กับผู้ขายที่ต่างกันสองรายและบริการที่แตกต่างกันสองรายการ ฉันพบว่าตัวเองต้องพิสูจน์เหตุผลที่บริการที่จำเป็นต้องมีการเปลี่ยนแปลง ผู้ขายระบุว่าลูกค้าควรรับมือกับสิ่งนี้และแม้แต่ห้องสมุด REST ที่ฉันเลือกก็ถูกตั้งคำถาม (RestEasy) เพราะไม่ได้จัดการกับสิ่งนี้ตามค่าเริ่มต้น 'นอกกรอบ' นี่เป็นจุดสำคัญของความยุ่งยาก ฉันไม่พบการอ้างอิงจำนวนมากเพื่อสำรองอาร์กิวเมนต์ของฉันฉันคิดว่านี่เป็นเพราะประเด็นนั้นเป็นที่สงสัยเนื่องจากมันชัดเจนมาก คำถามคือฉันหายไปบางอย่าง? ฉันเป็นคนหยาบคายเกี่ยวกับเรื่องนี้หรือไม่? ตกลงหรือไม่ที่จะมี JSON API ที่ไม่มีประเภทแอปพลิเคชัน / json ในสถานการณ์นี้ การอ้างอิงจะได้รับการชื่นชม คุณจะแก้ไขสถานการณ์นี้จากมุมมองทางการค้าได้อย่างไร

25 rest  api-design  json  bad-code 

สำหรับงานของฉันเรามี webservice สงบดีที่เราสร้างขึ้นที่เราใช้ในการขับเคลื่อนเว็บไซต์สองสามที่เรามี โดยทั่วไปเว็บเซอร์วิซให้คุณสร้างและทำงานกับตั๋วสนับสนุนและเว็บไซต์รับผิดชอบส่วนหน้า การร้องขอบริการเว็บเซอร์ใด ๆ ใช้ส่วนหัวรับรองความถูกต้องซึ่งเราใช้ในการตรวจสอบผู้ใช้และรหัสผ่านสำหรับการโทรแต่ละครั้ง ในปีนี้เราต้องการขยายตัวเลือกการเข้าสู่ระบบของเราเพื่อให้ผู้ใช้บนเว็บไซต์สามารถเข้าสู่ระบบผ่านทาง Google, Twitter และ Facebook อย่างไรก็ตามฉันมีปัญหามากมายในการหาวิธีการออกแบบสิ่งนี้ดังนั้นเว็บเซอร์วิซจึงสามารถใช้ผู้ให้บริการการพิสูจน์ตัวตนบุคคลที่สามเพื่อให้แน่ใจว่าผู้ใช้เป็นคนที่พวกเขาพูด มีวิธีปฏิบัติที่ดีที่สุดในการทำเช่นนี้หรือไม่? ขณะนี้เรากำลังคิดที่จะให้เว็บไซต์จัดการกับการรับรองความถูกต้องของผู้ใช้แล้วใช้การเรียก setSessionId ใหม่ที่ลงทะเบียนเซสชันปัจจุบันด้วยเว็บเซอร์แบ็กเอนด์ คำขอเพิ่มเติมแต่ละรายการไปยังเว็บเซอร์วิซจะส่งผ่าน sessionId นั้นและจะตรวจสอบความถูกต้อง สิ่งเหล่านี้ดูเหมือนจะโอเค แต่ฉันมีความรู้สึกที่ด้านหลังของหัวของฉันที่ฉันไม่ได้คิดเรื่องนี้ผ่านและทุกการเรียกดูฟอรั่มของฉันและการอ่านรายละเอียด Oauth และ openid เป็นเพียงทำให้ฉันสับสนมากขึ้น เคล็ดลับใด ๆ สำหรับวิธีแก้ไขปัญหานี้

25 web-services  rest  authentication  oauth  openid 

การพยายามออกแบบ API สำหรับแอปพลิเคชันภายนอกที่มีการคาดการณ์ล่วงหน้าสำหรับการเปลี่ยนแปลงนั้นไม่ใช่เรื่องง่าย แต่การคิดล่วงหน้าเล็กน้อยจะทำให้ชีวิตง่ายขึ้นในภายหลัง ฉันกำลังพยายามสร้างโครงร่างที่จะรองรับการเปลี่ยนแปลงในอนาคตในขณะที่ยังคงเข้ากันได้แบบย้อนกลับโดยปล่อยให้ตัวจัดการเวอร์ชันก่อนหน้าเข้าแทนที่ ข้อกังวลหลักของบทความนี้คือรูปแบบใดที่ควรปฏิบัติตามสำหรับจุดสิ้นสุดที่กำหนดไว้ทั้งหมดสำหรับผลิตภัณฑ์ / บริษัท ที่กำหนด โครงการฐาน ได้รับเทมเพลต URL ฐานของhttps://rest.product.com/ผมได้วางแผนว่าบริการทั้งหมดอาศัยอยู่ภายใต้/apiพร้อมกับ/authและปลายทางที่ไม่ใช่ส่วนที่เหลืออื่น ๆ /docเช่น ดังนั้นฉันสามารถสร้างจุดปลายพื้นฐานดังนี้: https://rest.product.com/api/... https://rest.product.com/auth/login https://rest.product.com/auth/logout https://rest.product.com/doc/... จุดบริการ ตอนนี้สำหรับปลายทางเอง ความกังวลเกี่ยวกับPOST, GET, DELETEไม่ได้เป็นวัตถุประสงค์หลักของบทความนี้และเป็นกังวลกับการกระทำเหล่านั้นเอง จุดปลายสามารถแบ่งออกเป็นเนมสเปซและการกระทำได้ แต่ละการกระทำจะต้องนำเสนอตัวเองในวิธีที่จะสนับสนุนการเปลี่ยนแปลงขั้นพื้นฐานในประเภทผลตอบแทนหรือพารามิเตอร์ที่จำเป็น การใช้บริการแชทสมมุติที่ผู้ใช้ที่ลงทะเบียนสามารถส่งข้อความเราอาจมีจุดสิ้นสุดดังต่อไปนี้: https://rest.product.com/api/messages/list/{user} https://rest.product.com/api/messages/send ตอนนี้เพื่อเพิ่มการรองรับเวอร์ชันสำหรับการเปลี่ยนแปลง API ในอนาคตซึ่งอาจแตกหัก เราสามารถเพิ่มลายเซ็นเวอร์ชันหลังจาก/api/หรือหลังจาก/messages/นั้น เมื่อกำหนดsendจุดสิ้นสุดเราจะได้สิ่งต่อไปนี้สำหรับ v1 https://rest.product.com/api/v1/messages/send https://rest.product.com/api/messages/v1/send ดังนั้นคำถามแรกของฉันคือสถานที่ที่แนะนำสำหรับตัวระบุรุ่นคืออะไร ผู้จัดการรหัสควบคุม ดังนั้นตอนนี้เราได้สร้างขึ้นแล้วเราจำเป็นต้องสนับสนุนเวอร์ชันก่อนหน้าดังนั้นเราจึงต้องจัดการกับรหัสสำหรับเวอร์ชั่นใหม่แต่ละเวอร์ชั่นซึ่งอาจเลิกใช้ไปตามกาลเวลา สมมติว่าเรากำลังเขียนจุดปลายใน Java เราสามารถจัดการสิ่งนี้ผ่านแพ็คเกจ package com.product.messages.v1; public interface MessageController { …

25 design  design-patterns  web-services  rest  services 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการ4 ปีที่แล้ว คุณจะเรียก API ที่ใช้ HTTP ใช้ URI เพื่อตั้งชื่อทรัพยากรและกริยา HTTP (PUT, POST, DELETE, GET ... ) เพื่อจัดการทรัพยากรเหล่านั้นอย่างไร ตามการร้องเรียนของ Roy Fieldingไม่ใช่การพักเนื่องจากไม่มีไฮเปอร์มีเดีย ภายในทีมของฉันทุกคนเรียกมันว่า "REST API" ฉันเรียกมันว่า "REST-like" แต่มันไม่ได้อธิบายและความหมายของมันนั้นคลุมเครือ ฉันค่อนข้างสับสนเกี่ยวกับเรื่องนี้เนื่องจากมีความขัดแย้งอย่างมากเกี่ยวกับ REST ฉันไม่ต้องการมีส่วนร่วมในสงครามไฟ แต่เพียงใช้คำที่ถูกต้อง

24 terminology  rest  api  http 

ฉันออกแบบ REST API สำหรับโครงการที่ผู้ใช้มักจะอยู่ใน "แผน" หนึ่งในหลาย ๆ แผน - แต่ละแผนกำหนดข้อ จำกัด ของทรัพยากรบางอย่างเช่นจำนวนผู้ใช้สูงสุดที่บัญชีอาจมีหรือจำนวนข้อมูลสูงสุดที่พวกเขาอาจอัปโหลด เมื่อถึงขีด จำกัด เหล่านี้ผู้ใช้สามารถอัปเกรดแผนของพวกเขา (จ่ายเป็นหลัก) เพื่อรับทรัพยากรเพิ่มเติม ฉันต้องการส่งคืนรหัสสถานะพิเศษที่ระบุสถานการณ์ที่ไม่สามารถดำเนินการได้เนื่องจากข้อ จำกัด ของทรัพยากรบัญชีและการอัปเกรดแผนจะแก้ไขปัญหานี้ - ตัวอย่างเช่นหากผู้ใช้ใช้ 100% ของความจุในการจัดเก็บและลองอัปโหลดไฟล์เพิ่มเติม พวกเขาจะได้รับคำตอบนี้ ผู้สมัครคือ IMHO: 403 Forbidden - อย่างไรก็ตามฉันต้องการแยกความแตกต่างระหว่างกรณีนี้และกรณีอื่น ๆ ที่ผู้ใช้ขาดสิทธิ์ในการดำเนินการนี้ 401 Unauthorized - ไม่ใช่ความคิดที่ดีเราใช้มันเพื่อตรวจสอบปัญหาที่เกี่ยวข้อง 402 Payment Required - ทำให้รู้สึก แต่ฉันกังวลเกี่ยวกับการใช้รหัสสถานะที่ไม่ได้มาตรฐาน แต่สงวนไว้ บางสิ่งที่เป็นมาตรฐานน้อยลงอย่าง423 Lockedที่ไม่น่าเป็นไปได้เราจะใช้มันเพื่อสิ่งอื่นในอนาคต ตัวเลือกอื่นคือไปกับสิ่งที่มาตรฐานมากเช่น403แต่ระบุเฉพาะข้อผิดพลาดในเนื้อหาการตอบสนอง ฉันสงสัยว่าวิธีการใดที่คุณเชื่อว่า (ก) จะทำงานได้ดีที่สุดในระยะยาวและ …

24 rest  api-design  http 

เรามีฐานข้อมูลทรัพยากรไม่ว่าจะเป็นผลิตภัณฑ์โพสต์บล็อกหรืออะไร เราจำเป็นต้องออกแบบชุดรูปแบบ URL เพื่อระบุที่อยู่สำหรับเว็บไซต์สาธารณะ นี่คือสองตัวอย่างที่ผูก ID ฐานข้อมูล: https://www.youtube.com/watch?v=7FPS6llqhXw http://www.amazon.co.uk/gp/product/B000NHOMSQ นี่คือตัวอย่างที่เป็นมิตร: http://en.wikipedia.org/wiki/LED_circuit (เหลือบเล็ก ๆ น้อย ๆ ในชีวิตการท่องของฉันมี) ฉันชอบ URL ที่จดจำง่ายเนื่องจากคุณมีความคิดเกี่ยวกับสิ่งที่อยู่ท้าย URL เมื่อคุณเลื่อนหรือดูในอีเมลหรือเอกสาร ดีกว่าสำหรับ SEO หรือเคยเป็นมาก่อน จะเกิดอะไรขึ้นเมื่อเปลี่ยนชื่อเอกสารหรือผลิตภัณฑ์ อาจเป็นเพราะมันเปลี่ยนไป (Wiki อาจไม่เปลี่ยนแปลง แต่ทรัพยากรของเราสามารถทำได้) หรือเนื่องจากพิมพ์ผิดใช่ไหม ทรัพยากรของเรานั้นมีทั้งเทคนิคคำพูดยาว ๆ และข้อผิดพลาด นอกจากนี้เรายังมี ID ฐานข้อมูลซึ่งเป็นตัวเลข ลองดูแนวคิดสำหรับที่อยู่ของวิดีโอโดยใช้ร้านเช่าที่ให้เช่า: http://vidsyeah.com/video/sliding-doors/287171 ID นั้นชัดเจนและถูกใช้ในการค้นหา DB ละเอียด. บิตบานเลื่อนไม่ซ้ำกันและเพิ่งสร้างจากชื่อวิดีโอมันสามารถตรวจสอบได้บน GET ดังนั้นหากเข้าประตูร่อนและไม่ตรงกับสิ่งที่อยู่ใน doc 287171 จริง ๆ แล้วมันจะตอบสนอง …

24 web-applications  rest  web  websites  http 

ในบทความนี้ผู้เขียนอ้างว่า บางครั้งจำเป็นต้องเปิดเผยการดำเนินการใน API ที่โดยทั่วไปจะไม่สงบ และนั่น หาก API มีการดำเนินการมากเกินไปนั่นเป็นข้อบ่งชี้ว่ามันได้รับการออกแบบด้วยมุมมอง RPC แทนที่จะใช้หลักการ RESTful หรือ API ที่เป็นปัญหานั้นเหมาะสมสำหรับรุ่นประเภท RPC โดยธรรมชาติ สิ่งนี้สะท้อนถึงสิ่งที่ฉันได้อ่านและได้ยินที่อื่นเช่นกัน อย่างไรก็ตามฉันพบว่ามันค่อนข้างสับสนและฉันต้องการทำความเข้าใจเกี่ยวกับเรื่องนี้ให้ดีขึ้น ตัวอย่างฉัน: การปิด VM ผ่านอินเตอร์เฟส REST ฉันคิดว่ามีสองวิธีที่แตกต่างกันในการสร้างแบบจำลองการปิดระบบของ VM แต่ละวิธีอาจมีรูปแบบต่างกันเล็กน้อย แต่เราจะมุ่งเน้นไปที่ความแตกต่างพื้นฐานที่สุดในตอนนี้ 1. แก้ไขคุณสมบัติสถานะของทรัพยากร PATCH /api/virtualmachines/42 Content-Type:application/json { "state": "shutting down" } (หรืออีกวิธีหนึ่งPUTบนทรัพยากรย่อย/api/virtualmachines/42/state) VM จะปิดระบบในพื้นหลังและในเวลาต่อมาขึ้นอยู่กับว่าการปิดเครื่องจะสำเร็จหรือไม่สถานะอาจได้รับการปรับปรุงภายในด้วย "ปิด" 2. ใส่หรือโพสต์บนคุณสมบัติการกระทำของทรัพยากร PUT /api/virtualmachines/42/actions Content-Type:application/json { "type": "shutdown" } …

24 rest  domain-driven-design  api-design  cqrs 

ฉันกำลังพยายามที่จะเข้าใจจุดของ Odata และเมื่อมันจะทำให้รู้สึก ตอนนี้ฉันทำงานอย่างไรฉันใช้ตัวควบคุม ASP.NET และ MVC / WebApi เพื่อทำให้เป็นอันดับ / ดีซีเรียลไลซ์ออบเจ็กต์ลงใน JSON และให้จาวาสคริปต์ทำอะไรบางอย่างกับมัน จากสิ่งที่ฉันสามารถบอกได้ว่าประโยชน์ของ OData นั้นสามารถสืบค้นได้โดยตรงจาก URL ... แต่เนื่องจากฉันเขียนรหัสลูกค้าและเซิร์ฟเวอร์ไม่จำเป็นต้องทำเช่นนั้น ใครบ้างที่เคยแยกผลลัพธ์ของแบบสอบถาม ODaya ใน javascript? บางที OData เป็นอีกเรื่องเกี่ยวกับการให้จุดสิ้นสุดทั่วไปสำหรับไคลเอนต์ทั้งหมดเพื่อรับข้อมูลรายละเอียดจากแบบสอบถามที่ JSON ไม่ได้ให้ ดังนั้นถ้าฉันเป็นผู้ให้บริการข้อมูลฉันคิดว่าเป็นสิ่งที่ Odata ใช้เพื่ออะไร ช่วยฉันเข้าใจวัตถุประสงค์และการใช้ REST / JSON / ODATA

23 javascript  rest  json 

สมมติว่าฉันมี บริษัท ที่จัดอันดับแมวที่น่ารักที่สุดในอินเทอร์เน็ต ฉันเสนอทรัพยากรที่/cats/ให้แมวที่น่ารักและน่ารักคนล่าสุด ผู้ใช้สามารถได้รับแมว 3 อันดับแรกหากพวกเขาไม่ได้ชำระเงินทั้งหมดหรือลงทะเบียน แมว 10 อันดับแรกถ้าพวกเขาจ่าย 337 ดอลลาร์และเข้าสู่ระบบและแมว 100 อันดับแรกถ้าพวกเขาจ่ายเงิน 1,337 ดอลลาร์และเข้าสู่ระบบฉันมี 'ตัวระบุผู้ใช้' เมื่อทำการร้องขอ ในระยะสั้นผู้บริโภค/cats/จะได้รับจำนวนที่แตกต่างกันของแมวอยู่บนพื้นฐานของพวกเขาใช้การจัดอันดับ ' ฉันมีตัวระบุผู้ใช้ในส่วนสิ้นเปลือง แต่ฉันไม่มีระดับตัวแทนผู้ใช้อย่างชัดเจนในส่วนสิ้นเปลือง ฉันต้องการแจ้งให้ผู้ใช้ทราบว่าพวกเขาสามารถอัพเกรดการสมัครสมาชิกเมื่อทำการร้องขอ นั่นคือฉันต้องการที่จะแยกแยะระหว่าง3 แมวตั้งแต่ผมเพียง แต่นำเสนอ 3 แมวและ3 แมวเนื่องจากว่าสิ่งที่ระดับผู้ใช้ที่ได้รับอนุญาต อะไรคือแนวปฏิบัติที่ดีที่สุดสำหรับการ จำกัด ทรัพยากรเนื่องจากผู้บริโภคมีสิทธิพิเศษไม่เพียงพอและ จำกัด เนื่องจากเป็นสิ่งที่ผู้บริโภคมี ลูกค้าจะรู้ได้อย่างไรว่าพวกเขาสามารถอัพเกรดการจัดอันดับของพวกเขา? นั่นคือพวกเขามีทรัพยากรที่ จำกัด เพราะพวกเขาไม่มีสิทธิ์ การปฏิบัติที่ดีที่สุดที่นี่คืออะไร? หมายเหตุนี่คือการทำให้เข้าใจง่ายโดยรวมของกรณีจริง นอกจากนี้เพื่อชี้แจง - อ่านชื่นชม ปรับปรุง: นี่คือตัวเลือกที่เราพิจารณาแล้ว: การจัดเก็บวัตถุการอนุญาตของผู้ใช้หนึ่งครั้งบนไคลเอนต์การสอบถามมันเมื่อดำเนินการเข้าสู่ระบบหรืออัพเกรดบัญชี การส่งผ่านnullค่าใน JSON บ่งชี้ว่ามีอยู่จริง แต่ไม่มีการถ่ายโอนจริง …

23 rest  http  url  http-response 

สมมติว่าระบบที่มีเว็บแอปพลิเคชันที่มีทรัพยากรและการอ้างอิงถึงแอปพลิเคชันระยะไกลที่มีทรัพยากรที่คล้ายกันอื่นคุณจะแสดงการดำเนินการซิงค์แบบสองทิศทางที่ประสานทรัพยากร 'ท้องถิ่น' กับทรัพยากร 'ระยะไกล' ได้อย่างไร ตัวอย่าง: ฉันมี API ที่แสดงรายการสิ่งที่ต้องทำ รับ / โพสต์ / วาง / ลบ / ลอส / ฯลฯ API นั้นสามารถอ้างอิงบริการสิ่งที่ต้องทำแบบรีโมต GET / POST / PUT / DELETE / todo_services / ฯลฯ ฉันสามารถจัดการ todos จากบริการระยะไกลผ่าน API ของฉันในฐานะตัวแทนผ่าน GET / POST / PUT / DELETE / todo_services / abc123 / …

23 api  rest  api-design  synchronization 

ฉันออกแบบ REST API ที่ใช้งานได้จริงและฉันติดอยู่กับวิธีเพิ่มเอนทิตีที่มีอยู่ในคอลเลกชัน โมเดลโดเมนของฉันมีโครงการที่มีไซต์ต่างๆ นี่เป็นความสัมพันธ์แบบกลุ่มต่อกลุ่มที่เข้มงวดและฉันไม่จำเป็นต้องสร้างเอนทิตีที่จำลองความสัมพันธ์อย่างชัดเจน (เช่น ProjectSite) API ของฉันจะช่วยให้ผู้บริโภคสามารถเพิ่มเว็บไซต์ที่มีอยู่ในโครงการ ที่ที่ฉันต้องวางสายคือข้อมูลเดียวที่ฉันต้องการจริงๆคือ ProjectId และ SiteId แนวคิดเริ่มต้นของฉันคือ: 1. POST myapi/projects/{projectId}/sites/{siteId} แต่ฉันก็คิดถึง 2. POST myapi/projects/{projectId}/sites ด้วยเอนทิตีของไซต์ที่ส่งเป็นเนื้อหา JSON ตัวเลือกที่ 1 นั้นง่ายและใช้งานได้ แต่รู้สึกไม่ถูกต้องและฉันมีความสัมพันธ์อื่น ๆ ที่ไม่สามารถทำตามรูปแบบนี้ดังนั้นมันจึงเพิ่มความไม่สอดคล้องกับ API ของฉัน ตัวเลือก 2 รู้สึกดีขึ้น แต่นำไปสู่ข้อกังวลสองข้อ: ฉันควรสร้างเว็บไซต์หรือส่งข้อยกเว้นหากมีการโพสต์ไซต์ใหม่ (SiteId = 0) เนื่องจากฉันต้องการเพียง ProjectId และ SiteId เพื่อสร้างความสัมพันธ์ไซต์อาจถูกโพสต์ด้วยข้อมูลที่ผิดหรือขาดหายไปสำหรับคุณสมบัติอื่น ๆ ตัวเลือกที่ 3 คือการจัดเตรียมจุดปลายอย่างง่ายเพียงอย่างเดียวสำหรับการสร้างและลบความสัมพันธ์ จุดสิ้นสุดนี้คาดว่าจะมี …

23 rest  api-design 

บริษัท ของฉันกำลังทำงานเกี่ยวกับการใช้สถาปัตยกรรมไมโครเซอร์วิส แต่เรากำลังเผชิญกับความเจ็บปวดที่เพิ่มขึ้นเรื่อย ๆ หนึ่งในประเด็นสำคัญที่เราเผชิญคือการสื่อสารข้อมูลจำนวนมากระหว่างบริการต่างๆของเรา ในฐานะที่เป็นพื้นหลังเรามีที่เก็บเอกสารที่ทำหน้าที่เป็นที่เก็บเอกสารใด ๆ ที่เราอาจต้องจัดการข้าม บริษัท การโต้ตอบกับร้านค้าดังกล่าวจะกระทำผ่านบริการที่ให้ลูกค้ามี ID ที่ไม่ซ้ำกันและสถานที่ในการสตรีมเอกสาร ตำแหน่งของเอกสารสามารถเข้าถึงได้ในภายหลังผ่านการค้นหาด้วย ID ที่ระบุ ปัญหาคือสิ่งนี้ - มันสมเหตุสมผลหรือไม่ที่ microservices ของเราทั้งหมดจะยอมรับ ID ที่ไม่ซ้ำกันนี้เป็นส่วนหนึ่งของ API ของพวกเขาเพื่อวัตถุประสงค์ในการโต้ตอบกับเอกสารหรือไม่? สำหรับฉันนี้รู้สึกผิดโดยเนื้อแท้ - บริการไม่เป็นอิสระอีกต่อไปและพึ่งพาบริการของที่เก็บเอกสาร ในขณะที่ฉันยอมรับว่าสิ่งนี้อาจทำให้การออกแบบ API ง่ายขึ้นและบางทีอาจมีประสิทธิภาพบางอย่างที่ทำให้เกิดการเชื่อมโยงมากกว่าผลประโยชน์ถ่วงดุล ไม่มีใครรู้ว่ารุ้งยูนิคอร์น (Netflix, Amazon, Google, ฯลฯ ) จัดการกับไฟล์ / การแลกเปลี่ยนข้อมูลขนาดใหญ่ระหว่างบริการของพวกเขา?

22 design  rest  xml  microservices 

ฉันกำลังสร้างเว็บแอปพลิเคชันธุรกิจใหม่และฉันต้องการบรรลุ: ใช้เทคโนโลยีที่ดีที่สุดจากอาณาจักรที่เกี่ยวข้อง ฉันต้องการกรอบแบ็กเอนด์ที่เชื่อถือได้ด้วย ORM ที่มั่นคง และฉันต้องการเฟรมเวิร์ก SPA (แอปพลิเคชันหน้าเดียว) ที่ทันสมัยที่สุดด้วยการใช้คุณสมบัติ HTML และ Javascript ล่าสุดสำหรับแอปพลิเคชันส่วนหน้า เปิดเผยเอนทิตีแบ็กเอนด์และบริการธุรกิจสำหรับการใช้งานจากแอพพลิเคชั่นประเภทต่าง ๆ เช่นเว็บแอพพลิเคชั่นมือถือ (Android) และประเภทอื่น ๆ (อุปกรณ์สมาร์ทเป็นต้น) ดังนั้น - เพื่อตอบสนองความต้องการทั้งสองอย่างฉันมีแนวโน้มที่จะแยกแอปพลิเคชันของฉันออกอย่างสมบูรณ์ในแอปพลิเคชันส่วนหลังและส่วนหน้าและจัดการการสื่อสารระหว่างกันโดยใช้ REST API (JSON) เสียงนี้เข้าใกล้หรือไม่? การแยกดังกล่าวไม่ใช่โซลูชันการออกแบบที่ชัดเจนเนื่องจากเทคโนโลยีเว็บแอปพลิเคชันจำนวนมากได้รวมเลเยอร์มุมมองไว้ซึ่งแอปพลิเคชันฝั่งเซิร์ฟเวอร์จะควบคุมการสร้างมุมมองมากขึ้นหรือน้อยลงและจัดการการตอบสนองจากมุมมองบางส่วน layer, Java JSF / Facelets จะบันทึกสถานะของส่วนประกอบบนเซิร์ฟเวอร์อย่างสมบูรณ์) ดังนั้น - มีเทคโนโลยีมากมายที่เสนอการมีเพศสัมพันธ์ที่แข็งแกร่งมากขึ้นและให้สัญญาว่าจะพัฒนาได้เร็วขึ้นและมีเส้นทางการเดินทางที่เป็นมาตรฐานมากขึ้น ดังนั้น - ฉันต้องระวังเมื่อเริ่มใช้เทคโนโลยีในลักษณะที่ไม่ได้ใช้กันอย่างแพร่หลาย ตามที่ฉันเข้าใจแล้วส่วนหน้าของ SPA ที่แยกจากกันอย่างสมบูรณ์มักเกิดจากความจำเป็นในการใช้ API ของบุคคลที่สาม แต่การออกแบบเสียง decoupling ดังกล่าวเมื่อทั้งสองแบ็กเอนด์และส่วนหน้าได้รับการพัฒนาโดย บริษัท หนึ่ง? …

21 design  rest  api  front-end  backend 

ฉันมีชุดผลิตภัณฑ์ในกลุ่มผลิตภัณฑ์เช่น: product-groups/123/products ถ้าฉันต้องการเพิ่มลงในคอลเลกชันฉันจะส่งผลิตภัณฑ์บางอย่างที่มี PUT ได้หรือไม่ หากฉันต้องการลบผลิตภัณฑ์บางอย่างออกจากคอลเลกชันฉันจะส่งข้อมูลตัวกรอง (อาร์เรย์ของ ID) ด้วย DELETE ได้หรือไม่ เป็นวิธีที่ดีที่สุดในการใช้งานฟังก์ชันในจิตวิญญาณของ ReST อะไร แก้ไข: รายการเหล่านี้เป็นลิงค์ไปยังเอนทิตีที่แยกจากกันโดยทั่วไปเป็น ID ของผลิตภัณฑ์

21 rest  collections