คำถามติดแท็ก client-server

เซิร์ฟเวอร์จำนวนมากที่ฉันจัดการจะส่งคืน HTTP 200 สำหรับคำขอที่ลูกค้าควรพิจารณาถึงความล้มเหลวโดยมี 'ความสำเร็จ: เท็จ' ในเนื้อความ ดูเหมือนว่าฉันจะใช้รหัส HTTP ไม่ถูกต้องกับฉันโดยเฉพาะในกรณีของการตรวจสอบสิทธิ์ที่ล้มเหลว ฉันได้อ่านรหัสข้อผิดพลาด HTTP โดยสังเขปแล้วสรุปว่า '4xx' บ่งชี้ว่าไม่ควรทำคำขออีกครั้งจนกว่าจะมีการเปลี่ยนแปลงในขณะที่ '5xx' แสดงว่าคำขอนั้นอาจจะใช้งานได้หรืออาจไม่ถูกต้อง แต่ก็ไม่สำเร็จ ในกรณีนี้ 200: การเข้าสู่ระบบล้มเหลวหรือ 200: ไม่พบไฟล์นั้นหรือ 200: พารามิเตอร์ที่หายไป x ดูเหมือนผิดปกติ ในทางกลับกันฉันเห็นการโต้แย้งว่า '4xx' ควรระบุปัญหาเชิงโครงสร้างของคำขอเท่านั้น ดังนั้นจึงเหมาะสมที่จะส่งคืน 200: ผู้ใช้ / รหัสผ่านไม่ดีแทนที่จะได้รับอนุญาต 401 เนื่องจากลูกค้าได้รับอนุญาตให้ทำการร้องขอ แต่มันเกิดขึ้นไม่ถูกต้อง อาร์กิวเมนต์นี้สามารถสรุปได้ว่าหากเซิร์ฟเวอร์สามารถประมวลผลคำขอและตัดสินใจได้ทั้งหมดรหัสการตอบสนองควรเป็น 200 และขึ้นอยู่กับลูกค้าที่จะตรวจสอบเนื้อหาสำหรับข้อมูลเพิ่มเติม โดยทั่วไปดูเหมือนว่าจะเป็นเรื่องของการตั้งค่า แต่นั่นไม่น่าพอใจดังนั้นถ้าใครมีเหตุผลว่าทำไมหนึ่งในกระบวนทัศน์เหล่านี้ถูกต้องมากขึ้นฉันอยากจะรู้

54 http  server  error-handling  client-server 

ในขณะที่ฉันเข้าใจว่า 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 

ฉันรู้ว่าเรามีข้อได้เปรียบพิเศษในการใช้คุกกี้ผ่านที่อยู่ IP แต่คำถามของฉันคือเหตุใดคอนเทนเนอร์ไม่สามารถจดจำที่อยู่ IP ของลูกค้าในการระบุลูกค้าเมื่อเขาเยี่ยมชมเว็บไซต์ของเขาอีกครั้ง เป็นไปได้ไหมที่คอนเทนเนอร์จะจดจำลูกค้าด้วยความช่วยเหลือของที่อยู่ IP?

26 http  session  networks  cookies  client-server 

ฉัน 100% ในคณะกรรมการที่มีกรณีที่หนึ่งควร แน่นอนใช้ทั้งฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ด้านการตรวจสอบข้อมูล อย่างไรก็ตามในกรอบงานและสภาพแวดล้อมที่ฉันได้ทำงานวิธีที่ฉันเห็นไม่เคยแห้ง เวลาส่วนใหญ่ไม่มีแผนหรือรูปแบบ - การตรวจสอบความถูกต้องถูกเขียนในสเป็คโมเดลและการตรวจสอบความถูกต้องจะถูกเขียนในแบบฟอร์มในมุมมอง (หมายเหตุ: ประสบการณ์มือแรกของฉันส่วนใหญ่คือ Rails, Sinatra และ PHP w / jQuery) ดูเหมือนว่ามันจะไม่ยากที่จะสร้างเครื่องกำเนิดไฟฟ้าซึ่งได้รับชุดการตรวจสอบความถูกต้อง (เช่นชื่อรุ่นเขตข้อมูลสภาพ) สามารถผลิตวัสดุทั้งฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ที่จำเป็น อีกทางหนึ่งเครื่องมือดังกล่าวสามารถทำการตรวจสอบความถูกต้องฝั่งเซิร์ฟเวอร์ (เช่นvalidatesรหัสในรูปแบบ ActiveRecord) และสร้างการตรวจสอบความถูกต้องฝั่งไคลเอ็นต์ (เช่นปลั๊กอิน jQuery ซึ่งจะถูกนำไปใช้กับแบบฟอร์ม เห็นได้ชัดว่าข้างต้นเป็นเพียง "เฮ้ฉันมีความคิดนี้" รำพึงและไม่ใช่ข้อเสนออย่างเป็นทางการ สิ่งนี้เป็นเรื่องยากกว่าที่คิดเมื่อฉันคิด นั่นนำมาสู่คำถาม: คุณจะออกแบบเทคนิค "การเขียนครั้งเดียวทำงานบนเซิร์ฟเวอร์และไคลเอนต์" ได้อย่างไรเพื่อการตรวจสอบข้อมูล หัวข้อย่อยที่เกี่ยวข้อง: เครื่องมือเช่นนี้มีอยู่สำหรับเฟรมเวิร์กเฉพาะหรือเทคโนโลยีไคลเอ็นต์เซิร์ฟเวอร์หรือไม่? gotchas หรือความท้าทายที่สำคัญด้วยการพยายามรักษาชุดตรวจสอบเพียงชุดเดียวคืออะไร

17 design  validation  dry  client-server 

ฉันกำลังสร้างเกมออนไลน์ครั้งแรกโดยใช้ socket.io และฉันต้องการให้เป็นเกมแบบผู้เล่นหลายคนแบบเรียลไทม์เช่น agar.io หรือ diep.io แต่ฉันพบปัญหาในการพยายามหาวิธีที่จะทำให้คอมพิวเตอร์ทั้งหมดทำงานด้วยความเร็วเดียวกัน ฉันมีสามแนวคิดสำหรับแบบจำลอง แต่ไม่มีแนวคิดใดที่ถูกต้องและฉันสงสัยว่าวิดีโอเกมปกติทำได้อย่างไร (คุณสามารถข้ามอ่านความคิดของฉันพวกเขาเพียงให้วิธีการดูปัญหาที่ฉันมี) เซิร์ฟเวอร์อนุญาตให้ไคลเอนต์ทำงานด้วยตนเองและส่งต่อการอัปเดตไปยังเซิร์ฟเวอร์ซึ่งจะส่งต่อไปยังไคลเอนต์ที่เหลือ นี่เป็นปัญหาที่คอมพิวเตอร์บางเครื่องทำงานได้เร็วกว่าเครื่องอื่น ๆ ทำให้พวกเขาอัปเดตเร็วขึ้นและเคลื่อนที่ข้ามหน้าจอเร็วขึ้น ให้เซิร์ฟเวอร์แจ้งให้ลูกค้าทราบเมื่อมีการอัปเดต ฉันสามารถรอจนกว่าลูกค้าคนสุดท้ายจะตอบสนอง (เป็นความคิดที่แย่มากในกรณีที่คนคนหนึ่งมีคอมพิวเตอร์ช้า) รอจนกว่าลูกค้าคนแรกจะตอบสนอง (อีกครั้งรอการสื่อสารก่อนแต่ละเฟรม) หรือเพียงแค่ส่งพวกเขาให้เร็วที่สุด ดูเหมือนว่าจะพบปัญหาเดียวกันกับหมายเลข 1) ที่จุดเริ่มต้นของเกมให้เซิร์ฟเวอร์บอกกับลูกค้าถึงวิธีการอัปเดตอย่างรวดเร็ว นี่หมายความว่าลูกค้าจะต้องรับผิดชอบในการ จำกัด การเคลื่อนไหวในช่วงเวลานั้น ตัวอย่างเช่นหากมีคนจัดการกดปุ่มสองครั้งภายในช่วงเวลานั้นก็จะส่งเหตุการณ์กดปุ่มเพียงปุ่มเดียว นี่เป็นปัญหาที่การดำเนินการบางอย่างอาจถูกเพิกเฉย (เช่นการกดปุ่มสองครั้ง) และการโต้ตอบจะขึ้นอยู่กับนาฬิกาของลูกค้าซึ่งอาจไม่ตรงกับนาฬิกาของเซิร์ฟเวอร์ เซิร์ฟเวอร์จะต้องติดตามลูกค้าแต่ละรายและตรวจสอบให้แน่ใจว่ามีการส่งการอัปเดตในเวลาที่ถูกต้อง ฉันได้ทำการค้นคว้าแล้ว แต่บทความที่ฉันอ่านดูเหมือนจะไม่เจาะจงว่าจะทำอย่างไรถ้าลูกค้าส่งการอัพเดตเร็วกว่าไคลเอนต์อื่น ๆ ในกรณีของฉันฉันกำลังติดต่อกับคนที่มีความเร็วแป้นพิมพ์เร็วกว่า (คอมพิวเตอร์จะส่งการอัปเดตแป้นพิมพ์มากกว่าคอมพิวเตอร์เครื่องอื่น) โปรแกรมเมอร์มักจะจัดการกับเรื่องนี้อย่างไร

15 client-server  real-time 

ใน บริษัท ของเราเราต้องสร้างเว็บอินเตอร์เฟสบนแพลตฟอร์มลินุกซ์ในตัว ฉันเห็นตัวเลือก 2 แบบ: คุณใช้เทคโนโลยีที่ HTML และ JavaScript ถูกสร้างขึ้นบนฝั่งเซิร์ฟเวอร์ (คิดว่า JSP, Grails แต่เป็นสิ่งที่ใช้ C ++ และสร้าง HTML / JavaScript) หรือคุณสร้าง 'ไคลเอนต์' HTML5 แอ็พพลิเคชันที่พูดถึง JSON หรือ XML สร้างแบ็กเอนด์ ฉันมีความรู้สึกว่าปัจจุบันเว็บแอปพลิเคชันมักจะไปกับสิ่งที่ตามมา แต่ข้อดีของการทำเช่นนั้น (นักพัฒนาในโครงการเลือกอดีตส่วนใหญ่ขึ้นอยู่กับความจริงที่ว่าพวกเขารู้ C ++ ดีกว่า HTML และ Javascript)

13 technology  client-server 

ในแง่ของสถาปัตยกรรมซอฟต์แวร์และการออกแบบ microservices "stack up" (เล่นสำนวนเจตนา) กับมิดเดิลแวร์อย่างไร ฉันมาจาก Java และดูเหมือนว่าเมื่อคุณย้ายออกจาก REST แบบตรงเป็น API และแยกแยะเลเยอร์และพารามิเตอร์การเชื่อมต่อต่าง ๆ อย่างน้อยที่สุดใน Java คุณเกือบจะกลับมาที่ความคิดเก่า ๆ . เราได้กลับมาสู่การจำลองเสมือน ... ซึ่ง JVM นั้นเสมือนจริงอยู่แล้ว ด้วยวิธีที่ไม่เชื่อเรื่องพระเจ้าคุณสามารถและฉันจะเถียงข้อได้เปรียบที่เป็นนามธรรม, สงบเงียบ API กับ CORBA หรือในทางที่มีจาวาเป็นศูนย์กลางมากกว่า JMS หรือ MDB ในครั้งเดียว EJB เป็นเรื่องใหญ่ใน Java แล้วมันได้รับการยอมรับว่าเป็นกลุ่มของคลัสเตอร์ แต่ตอนนี้เรากลับไปที่จุดเริ่มต้นหรือไม่? หรือ microservices เสนอสิ่งที่ CORBA หรือดีกว่า MDB ขาดหรือไม่ เมื่อฉันอ่าน (TLDR) มาร์ตินฟาวเลอร์อธิบายการใช้ไมโครไซต์มันจะทำให้ฉันเป็นทางออกที่ดีสำหรับปัญหาที่ไม่ดีถ้าคุณต้องการ หรือค่อนข้างเป็นวิธีการปิดที่เปิดใจซึ่งนำเสนอระดับของความซับซ้อนเพียงผลักดันปัญหาไปรอบ …

9 java  enterprise-architecture  distributed-computing  client-server  middleware