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

ฉันกำลังทำงานในโครงการกับองค์กรดังต่อไปนี้: ไคลเอ็นต์ - รับข้อมูลจากเซิร์ฟเวอร์หลักผ่าน REST api เซิร์ฟเวอร์ - ร้องขอข้อมูลจากเซิร์ฟเวอร์อื่น ๆ ผ่าน API ของบุคคลที่สาม API ของบุคคลที่สาม - บริการอยู่นอกเหนือการควบคุมของฉันที่ให้ข้อมูลกับเซิร์ฟเวอร์ (Reddit, Hackernews, Quora ฯลฯ ) เพื่อประโยชน์ในการโต้แย้งสมมติว่าลูกค้าต้องการรายการจาก API บุคคลที่สามแต่ละรายการก่อน จากรายการนี้รายการจะถูกเลือก ณ จุดที่ลูกค้าต้องการดูเนื้อหาทั้งหมดของรายการรวมถึงการตอบกลับ (เช่นความคิดเห็น) ไปยังรายการ ฉันพยายามตัดสินใจระหว่างสามตัวเลือก: อาหารตามสั่ง ในวิธีการนี้ฉันจะมีจุดสิ้นสุด 3 จุดแยกกันบนเซิร์ฟเวอร์ของฉัน: รายการหนึ่งเพื่อรับรายการรายการหนึ่งรายการเพื่อรับเนื้อหาหลักสำหรับรายการและอีกรายการหนึ่งเพื่อรับการตอบกลับของรายการ ข้อดี: ฉันไม่เคยขอมากกว่าที่ต้องการการร้องขอควรมีขนาดเล็กดังนั้นโดยทั่วไปพวกเขาควรจะเร็วกว่า ข้อด้อย: ฉันต้องขอจำนวนมาก หลังจากเลือกรายการจากรายการผู้ใช้อาจต้องรอก่อนเห็นเนื้อหาหลักจากนั้นรออีกนานเพื่อดูการตอบกลับ แคชฝั่งเซิร์ฟเวอร์ ในคำขอนี้ฉันจะโทรหาเซิร์ฟเวอร์ของฉันเพื่อ "ดึง" ข้อมูลทั้งหมดสำหรับแหล่งที่มาทั้งหมด ข้อมูลจะถูกแคชบนเซิร์ฟเวอร์ จากนั้นไคลเอ็นต์จะมีจุดสิ้นสุด REST แบบเดิมเหมือนกันยกเว้นจะไม่มีการรอระหว่างการโทรเนื่องจากเซิร์ฟเวอร์ของฉันมีข้อมูลอยู่แล้วและจะต้องป้อนให้กับลูกค้า ข้อดี: …

49 design  rest  api-design  server 

ฉันสงสัยเกี่ยวกับเรื่องนี้ สมมติว่าฉันมีuserทรัพยากรด้วยidและnameสาขา ถ้าฉันต้องการอัปเดตฟิลด์ฉันสามารถทำคำขอแพทช์กับทรัพยากรเช่นนี้ได้ PATCH /users/42 {"name": "john doe"} จากนั้นแอปพลิเคชันจะอัปเดตชื่อผู้ใช้ 42 แต่ทำไมถ้าฉันทำซ้ำคำขอนี้ผลลัพธ์จะแตกต่างกันอย่างไร อ้างอิงจากRFC 5789 PATCH นั้นไม่ปลอดภัยหรือ idempotent

48 rest  api-design  http  web-api 

ฉันกำลังสร้าง RESTful API ที่รองรับการจัดคิวงานระยะยาวเพื่อการจัดการในที่สุด เวิร์กโฟลว์ทั่วไปสำหรับ API นี้จะเป็น: ผู้ใช้กรอกข้อมูลในแบบฟอร์ม ลูกค้าโพสต์ข้อมูลไปยัง API API ส่งคืนยอมรับ 202 ลูกค้าเปลี่ยนเส้นทางผู้ใช้ไปยัง URL ที่ไม่ซ้ำกันสำหรับคำขอนั้น ( /results/{request_id}) ~ ~ ในที่สุด URL ที่ลูกค้าเยี่ยมชมอีกครั้งและเห็นผลลัพธ์ในหน้านั้น ปัญหาของฉันอยู่ในขั้นตอนที่ 6 ทุกครั้งที่ผู้ใช้เยี่ยมชมหน้าเว็บฉันจะส่งคำขอไปยัง API ของฉัน ( GET /api/results/{request_id}) เป็นการดีที่งานจะเสร็จสมบูรณ์ในขณะนี้และฉันจะส่งคืน 200 OK พร้อมผลลัพธ์ของงานของพวกเขา แต่ผู้ใช้มีความเร่งรีบและฉันคาดหวังว่าการรีเฟรชมากเกินไปเมื่อผลลัพธ์ยังไม่เสร็จสิ้นการประมวลผล ตัวเลือกที่ดีที่สุดของฉันสำหรับรหัสสถานะคืออะไร: คำขอนี้มีอยู่ มันยังไม่เสร็จ แต่มันก็ไม่ได้ล้มเหลว ฉันไม่ได้คาดหวังว่าจะมีรหัสเดียวในการสื่อสารทั้งหมด แต่ฉันต้องการสิ่งที่ให้ฉันส่งเมทาดาทาแทนที่จะให้ลูกค้าคาดหวังเนื้อหา มันสมเหตุสมผลแล้วที่จะส่งคืนค่า 202 เนื่องจากไม่มีความหมายอื่นที่นี่: เป็นGETคำขอดังนั้นจึงไม่มีสิ่งใดที่จะเป็น "ยอมรับ" นั่นจะเป็นตัวเลือกที่สมเหตุสมผลหรือไม่ ทางเลือกที่ชัดเจนสำหรับสิ่งนี้ทั้งหมด - …

47 rest  http 

สมมติว่า REST API ตอบกลับGETคำขอHTTP ส่งคืนข้อมูลเพิ่มเติมบางอย่างในวัตถุย่อยowner: { id: 'xyz', ... some other data ... owner: { name: 'Jo Bloggs', role: 'Programmer' } } เห็นได้ชัดว่าเราไม่ต้องการให้ใครPUTกลับมา { id: 'xyz', ... some other data ... owner: { name: 'Jo Bloggs', role: 'CEO' } } และประสบความสำเร็จ อันที่จริงเราอาจไม่ได้ใช้วิธีการที่อาจประสบความสำเร็จในกรณีนี้ แต่คำถามนี้ไม่เพียงเกี่ยวกับวัตถุย่อย: โดยทั่วไปแล้วจะทำอย่างไรกับข้อมูลที่ไม่ควรแก้ไขได้ในคำขอ PUT มันควรจะต้องหายไปจากคำขอ PUT หรือไม่ มันควรจะถูกทิ้งอย่างเงียบ ๆ …

46 rest  http  http-request 

ตามหลักการ REST ฉันต้องการสร้างวิธีการ GET สำหรับ API ของฉันที่ทำการค้นหาโดยใช้เกณฑ์บางอย่างและส่งคืนผลลัพธ์ให้กับลูกค้า ปัญหาคือเกณฑ์สามารถมีพารามิเตอร์ได้มากถึง 14 พารามิเตอร์โดยหนึ่งในนั้นคือรายการของวัตถุที่ซับซ้อนดังนั้น ... ฉันไม่รู้ด้วยซ้ำว่าเป็นไปได้ในการเข้ารหัส / ถอดรหัสวัตถุที่ซับซ้อนเหล่านี้ไปยัง / จากพารามิเตอร์ url ฉันไม่ได้คำนวณระยะเวลาที่ URL จะได้รับ แต่ฉันแน่ใจว่ามันจะมีขนาดใหญ่พอและอาจถึงขีด จำกัด ของ URL ได้หรือไม่ นอกจากนี้การค้นหาควรแสดงผลลัพธ์ใน "เรียลไทม์" ฉันหมายความว่าทุกครั้งที่ผู้ใช้เปลี่ยนบางสิ่งจากแบบฟอร์มการค้นหาเขาควรจะเห็นผลลัพธ์ใหม่โดยไม่ต้องกดปุ่ม "ค้นหา" ใด ๆ คุณช่วยอธิบายประเด็นเหล่านี้ให้ฉันหน่อยได้มั้ยและอะไรคือคำแนะนำของคุณในการสร้างวิธีการค้นหาแบบพักผ่อนด้วยพารามิเตอร์จำนวนมาก?

44 rest  api 

ฉันกำลังรวบรวมข้อมูลจำเพาะสำหรับบริการ REST ซึ่งเป็นส่วนหนึ่งที่จะรวมความสามารถในการเร่งความเร็วให้กับผู้ใช้ทั้งในกลุ่มและรายบุคคล เท่ากันหมดเวลาสำหรับสิ่งเหล่านี้จะสามารถกำหนดค่าต่อทรัพยากร / กลุ่ม / บริการ ฉันแค่ดูข้อมูลจำเพาะ HTTP 1.1 และพยายามตัดสินใจว่าจะสื่อสารกับลูกค้าอย่างไรว่าคำขอจะไม่ได้รับการตอบสนองเพราะพวกเขาถึงขีด จำกัด แล้ว ตอนแรกฉันคิดว่ารหัสลูกค้า403 - Forbiddenเป็นรหัสแต่จากสเป็ค: การอนุญาตจะไม่ช่วยและไม่ควรทำซ้ำการร้องขอ รบกวนฉัน ปรากฏขึ้นจริงว่า503 - Service Unavailableเป็นสิ่งที่ดีกว่าที่จะใช้ - เพราะมันช่วยให้การสื่อสารของเวลาลองผ่านการใช้Retry-Afterส่วนหัว เป็นไปได้ว่าในอนาคตฉันอาจมองหาการสนับสนุน 'ซื้อ' คำขอเพิ่มเติมผ่านทางอีคอมเมิร์ซ (ในกรณีนี้มันจะดีถ้ารหัสลูกค้า402 - Payment Requiredได้รับการสรุป!) - แต่ฉันคิดว่านี่อาจถูกบีบให้เป็นการตอบสนอง 503 เช่นกัน คุณคิดว่าฉันควรใช้อันไหน หรือมีอีกอย่างที่ฉันไม่ได้พิจารณา?

43 web-services  rest  http 

ฉันเคยใช้SignalRฟังก์ชั่นส่งข้อความตามเวลาจริงในหลายโครงการของฉัน ดูเหมือนว่าจะทำงานได้อย่างน่าเชื่อถือและง่ายต่อการเรียนรู้ที่จะใช้ อย่างน้อยที่สุดสิ่งล่อใจสำหรับฉันคือการละทิ้งการพัฒนาบริการ Web API และใช้SignalRสำหรับทุกสิ่ง ฉันรู้สึกว่าสิ่งนี้สามารถทำได้โดยการออกแบบอย่างรอบคอบและถ้าเป็นเช่นนั้นก็จะหมายความว่ารหัสลูกค้าน้อยกว่าจะจำเป็น ที่สำคัญกว่านั้นก็หมายความว่าจะมีอินเทอร์เฟซเดียวกับบริการมากกว่าแยกส่วนและในกรณีที่เลวร้ายที่สุดที่หนึ่งสามารถเชื่อมต่อนี้โดยไม่ต้องคิดเกี่ยวกับเมื่อสิ่งที่ได้รับการแสดง ฯลฯ ดังนั้นฉันอยากรู้ว่า: มีเหตุผลอื่นใดอีกหรือไม่ที่จะไม่ใช้ SignalR แทนบริการเว็บทั้งหมดนอกเหนือจากประสิทธิภาพ ประสิทธิภาพของ SignalR นั้นเพียงพอหรือไม่เกี่ยวกับเรื่องนี้ มันเป็นความฝันของฉันมานานแล้วที่จะสามารถแปลวัตถุฝั่งเซิร์ฟเวอร์และคำจำกัดความการบริการเป็นรหัสการเข้าถึงบริการฝั่งไคลเอ็นต์โดยไม่มีอะไรโง่node.jsๆ ตัวอย่างเช่นถ้าฉันกำหนดวัตถุที่น่าสนใจInterestingObjectและบริการไปCRUDยังวัตถุInterestingObjectServiceฉันสามารถกำหนดเส้นทาง URL มาตรฐานไปยังบริการ - พูดว่า "/ {serviceName} / {methodName}" - แต่ฉันยังคงต้องเขียนรหัสลูกค้าเพื่อเข้าถึง บริการ. เนื่องจากวัตถุจะถูกส่งผ่านจากไคลเอนต์ไปยังเซิร์ฟเวอร์และย้อนกลับจึงไม่มีเหตุผลเชิงปฏิบัติที่จะมีเพื่อกำหนดวัตถุอย่างชัดเจนในรหัสฝั่งไคลเอ็นต์และไม่จำเป็นต้องกำหนดเส้นทางเพื่อดำเนินการ CRUD อย่างชัดเจน ฉันรู้สึกว่าควรมีวิธีที่จะทำให้มาตรฐานทั้งหมดนี้เป็นไปได้ในการเขียนไคลเอนต์ภายใต้สมมติฐานที่ว่าการเข้าถึงบริการทำงานจากไคลเอนต์ไปยังเซิร์ฟเวอร์และกลับมาอย่างโปร่งใสเหมือนที่ฉันเขียน WinForms หรือ Java Applet หรือ Native App หรือสิ่งที่มีคุณ หาก SignalR นั้นดีพอที่จะใช้แทนเว็บเซอร์วิสแบบดั้งเดิมมันอาจเป็นวิธีที่ปฏิบัติได้เพื่อให้บรรลุเป้าหมายนี้ SignalR มีฟังก์ชั่นเพื่อทำให้ฮับทำงานเหมือนบริการที่ฉันอธิบายดังนั้นฉันสามารถกำหนดบริการทั่วไป (CRUD) ที่จะให้ฟังก์ชั่นทั้งหมดนี้นอกกรอบพร้อมภาพสะท้อนบางอย่าง จากนั้นฉันเกือบจะสามารถรับสิทธิ์ในการเข้าถึงบริการได้ช่วยให้ฉันรำคาญกับการเขียนรหัสใหม่เพื่อเข้าถึงสิ่งที่สามารถเข้าถึงได้โดยการประชุม - …

42 design-patterns  rest  web-api  websockets 

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

40 object-oriented  object-oriented-design  rest 

ฉันกำลังทำงานผ่านการออกแบบ RESTful API เรารู้ว่าเราต้องการส่งคืน JSON และ XML สำหรับทรัพยากรที่กำหนด ฉันคิดว่าเราจะทำสิ่งนี้: GET /api/something?param1=value1 Accept: application/xml (or application/json) อย่างไรก็ตามมีบางคนที่ใช้ส่วนขยายสำหรับสิ่งนี้เช่น: GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1) อะไรคือการแลกเปลี่ยนกับวิธีการเหล่านี้? เป็นการดีที่สุดที่จะพึ่งพาส่วนหัวการยอมรับเมื่อไม่ได้ระบุนามสกุล แต่ให้เกียรตินามสกุลเมื่อระบุ? มีข้อเสียเปรียบกับวิธีการนั้นหรือไม่?

40 architecture  web-services  rest  http 

สมมติว่าเรามีทรัพยากรเช่นนี้ book: type: object properties: author: {type: string} isbn: {type: string} title: {type: string} books: type: array items: book ดังนั้นเมื่อมีคนทำGETทรัพยากรหนังสือเราจะคืนสิ่งต่อไปนี้ [{"author": "Dan Brown", "isbn": "123456", "title": "Digital Fortress"}, {"author": "JK Rowling", "isbn": "234567", "title": "Harry Potter and the Chamber of Secrets"}] ฉันได้ยินจากคนในที่ทำงานว่าวิธีปฏิบัติที่เหลือแนะนำให้กลับคำตอบเป็นวัตถุ JSON ซึ่งหมายความว่า schema ของเราสำหรับbooksจะมีลักษณะเช่นนี้ books: type: object properties: …

40 rest  json 

พูดในแอปพลิเคชันของฉันผู้ใช้บางรายให้นามสกุลกับเรา ในการตอบสนอง REST API ร่างกายที่ต้องการ: ด้วยค่า "null": {"firstName": "Bob", "lastName": null} หรือคีย์ที่หายไป: {"firstName": "Bob"}

40 rest  api-design  json 

ฉันเสนอการเปลี่ยนแปลงโครงการซอฟต์แวร์ที่ได้รับการออกแบบมาไม่ดีนักซึ่งมีปัญหามากมาย ในระดับสูงโครงการใช้ Angular บน front-end และใช้ REST APIs ต่างๆ ซึ่งเป็นสิ่งที่ยอดเยี่ยม (ฉันไม่เห็นความจำเป็นในการเปลี่ยนแปลงเทคโนโลยีหรือเครื่องมือของเรา) ปัญหาคือรหัสฐานมีขนาดใหญ่กว่าใน API มากกว่าฝั่งเซิร์ฟเวอร์ ตรรกะทางธุรกิจส่วนใหญ่อาศัยอยู่ใน UI ด้วย REST APIs ที่เป็นอินเตอร์เฟสฐานข้อมูล CRUD อย่างง่ายไปยังเลเยอร์ UI ตัวอย่างเช่น POST ให้กับลูกค้าจะสร้างระเบียนลูกค้าในขณะที่ PUT จะแก้ไขลูกค้ารายนั้น ไม่มากและไม่มากน้อย อย่างไรก็ตามตรรกะทางธุรกิจของเรานั้นมีความต้องการมากกว่านั้น กระบวนการทั่วไปในการสร้างลูกค้านั้นค่อนข้างมากกว่าการแทรก 1 บันทึกฐานข้อมูล มันจะจัดเตรียมข้อมูลในตารางที่จำเป็นอื่น ๆ ทำการตรวจสอบความถูกต้องและการคำนวณบางอย่าง ฯลฯ ฉันต้องการทำการเรียก POST / PUT หนึ่งครั้งเพื่อสรุปพฤติกรรมทั้งหมดนี้เพื่อลดภาระของลูกค้าที่บริโภค ดังนั้นมุมมองของฉันคือว่า orchestration ที่ครอบคลุมนี้ควรมีชีวิตอยู่บนเซิร์ฟเวอร์ (ที่เรามีการควบคุมเต็มรูปแบบบันทึก ฯลฯ ) ไม่ใช่ UI …

37 rest  api-design  enterprise-architecture 

เมื่อพูดถึง API ของ JSON เป็นวิธีปฏิบัติที่ดีในการแผ่การตอบสนองออกและหลีกเลี่ยงวัตถุ JSON ที่ซ้อนกันหรือไม่ ตัวอย่างเช่นสมมติว่าเรามี API คล้ายกับ IMDb แต่สำหรับวิดีโอเกม มีหน่วยงานคู่เกมแพลตฟอร์ม ESRBRating และ GamePlatformMap ซึ่งทำแผนที่เกมและแพลตฟอร์ม สมมติว่าคุณร้องขอ / เกม / 1 ซึ่งดึงข้อมูลเกมด้วย ID 1 และส่งคืนออบเจ็กต์เกมด้วยแพลตฟอร์มและการซ้อนทับซ้อน { "id": 1, "title": "Game A", "publisher": "Publisher ABC", "developer": "Developer DEF", "releaseDate": "2015-01-01", "platforms": [ {"id":1,"name":"Xbox"}, {"id":2,"name":"Playstation"} ], "esrbRating": { "id": 1, "code": …

37 design  rest  api-design  json 

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

36 rest  soa  resources  implementations 

ฉันกำลังเริ่มโครงการ Java ใหม่ซึ่งจะต้องมี RESTful API มันจะเป็นแอปพลิเคชันธุรกิจ SaaS ที่ให้บริการลูกค้ามือถือ ฉันได้พัฒนาโครงการหนึ่งกับ Java EE 6 แต่ฉันไม่คุ้นเคยกับระบบนิเวศมากนักเนื่องจากประสบการณ์ส่วนใหญ่ของฉันอยู่บนแพลตฟอร์ม Microsoft ซึ่งจะเป็นตัวเลือกที่เหมาะสมสำหรับการใช้งาน JAX-RS สำหรับโครงการใหม่เช่นที่อธิบายไว้ ตัดสินจากรายการของวิกิพีเดียดูเหมือนว่าคู่แข่งหลักคือ Jersey, Apache CXF, RESTeasy และ Restlet แต่การเปรียบเทียบการนำ JAX-RS ไปใช้ในวิกิพีเดียนั้นมาจากปี 2008 ความประทับใจครั้งแรกของฉันจากหน้าแรกของพวกเขาคือ: CXFตั้งเป้าหมายที่จะเป็นโซลูชั่นที่ครอบคลุมมาก (เตือนให้ฉันนึกถึง WCF ในพื้นที่ของ Microsoft) ซึ่งทำให้ฉันคิดว่ามันมีความซับซ้อนในการเข้าใจการตั้งค่าและการดีบักมากกว่าสิ่งที่ฉันต้องการ Jerseyเป็นการนำมาใช้อ้างอิงและอาจเป็นทางเลือกที่ดี แต่เป็นมรดกจาก Sun และฉันไม่แน่ใจว่า Oracle จัดการกับมันอย่างไร (หน้าประกาศไม่ทำงานและการแจ้งเตือนครั้งล่าสุดจาก 4 เดือนก่อน); RESTeasyมาจาก JBoss และอาจเป็นตัวเลือกที่ดีแม้ว่าฉันจะไม่แน่ใจเกี่ยวกับการเรียนรู้ ดูเหมือนว่าRestletจะได้รับความนิยม แต่มีประวัติมากมายฉันไม่แน่ใจว่ามันทันสมัยใน Java …

35 java  rest  java-ee