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

ฉันออกแบบเว็บแอปพลิเคชั่นใหม่ซึ่งขับเคลื่อนโดยแบ็กเอนด์ REST และส่วนหน้า HTML + JS มีวิธีการPOSTหนึ่งวิธีในการเปลี่ยนเอนทิตีหนึ่ง (ลองเรียกใช้การกำหนดค่า) ซึ่งมีผลข้างเคียงหลายอย่างในสถานะขององค์ประกอบหลายอย่างของแอปพลิเคชัน สมมติว่ามีการดำเนินการPOSTด้วยวิธีนี้: POST /api/config BODY {config: ....} ด้วยเหตุนี้ฉันจึงต้องการแสดงตัวอย่างก่อนที่จะทำการเปลี่ยนแปลงเหล่านั้นเพื่อให้ผู้ใช้สามารถสังเกตเห็นสิ่งที่กำลังจะเปลี่ยนแปลง สิ่งแรกที่ฉันคิดเกี่ยวกับการทำให้จุดสิ้นสุดGETสำหรับการแสดงตัวอย่างส่งเนื้อความของสถานะใหม่ของเอนทิตี ทางนี้: GET /api/preview/items BODY {config: ....} อาจแสดงสถานะใหม่สำหรับรายการที่มีการกำหนดค่าใหม่ GET /api/preview/sales BODY {config: ....} อาจแสดงสถานะใหม่สำหรับการขายด้วยการกำหนดค่าใหม่ ดูเหมือนว่าเป็นความคิดที่ดีที่จะใช้คำกริยาGETเพราะฉันไม่ได้เปลี่ยนสถานะของแอปพลิเคชัน อย่างไรก็ตามการใช้ของร่างกายร้องขอกับGETคำขอดูเหมือนว่าจะท้อแท้ มีวิธีปฏิบัติที่ดีเกี่ยวกับเรื่องนี้หรือไม่? ตัวเลือกอื่นอาจจะเก็บการกำหนดค่าเป็นแบบร่างด้วยวิธีการหนึ่งและแสดงผลลัพธ์กับผู้อื่น แต่จะต้องมีขั้นตอนเพิ่มเติมและต้องจัดการแบบร่างในเซิร์ฟเวอร์: POST /api/preview/config BODY {config: ....} GET /api/preview/items?idPreviewConfig=1

17 programming-practices  rest  http 

ฉันกำลังสร้าง RESTful API ที่ใช้โทเค็น JWT สำหรับการรับรองความถูกต้องของผู้ใช้ (ที่ออกโดยloginปลายทางและส่งในส่วนหัวทั้งหมดหลังจากนั้น) และโทเค็นต้องได้รับการรีเฟรชหลังจากระยะเวลาคงที่ (เรียกrenewจุดสิ้นสุด ) เป็นไปได้ว่าเซสชัน API ของผู้ใช้จะไม่ถูกต้องก่อนที่โทเค็นจะหมดอายุดังนั้นจุดสิ้นสุดทั้งหมดของฉันเริ่มต้นด้วยการตรวจสอบว่า: 1) โทเค็นยังคงถูกต้องและ 2) เซสชันของผู้ใช้ยังคงถูกต้อง ไม่มีวิธีในการทำให้โทเค็นเป็นโมฆะโดยตรงเนื่องจากไคลเอนต์เก็บไว้ในเครื่อง ดังนั้นจุดสิ้นสุดของฉันทั้งหมดต้องส่งสัญญาณให้ลูกค้าทราบถึงสองเงื่อนไขที่เป็นไปได้: 1) ถึงเวลาต่ออายุโทเค็นหรือ 2) เซสชันนั้นไม่ถูกต้องและพวกเขาไม่ได้รับอนุญาตให้เข้าถึงระบบอีกต่อไป ฉันสามารถนึกถึงทางเลือกสองทางสำหรับจุดสิ้นสุดของฉันในการส่งสัญญาณลูกค้าเมื่อเกิดหนึ่งในสองเงื่อนไข (สมมติว่าลูกค้าสามารถปรับให้เข้ากับตัวเลือกใดตัวเลือกหนึ่ง): ส่งคืนรหัส http 401 (ไม่ได้รับอนุญาต) หากเซสชันไม่ถูกต้องหรือส่งคืนรหัส 412 (เงื่อนไขเบื้องต้นล้มเหลว) เมื่อโทเค็นหมดอายุและถึงเวลาเรียกrenewจุดสิ้นสุดซึ่งจะส่งคืนรหัส 200 (ok) ส่งคืน 401 สำหรับการส่งสัญญาณว่าเซสชันไม่ถูกต้องหรือโทเค็นหมดอายุแล้ว ในกรณีนี้ลูกค้าจะโทรหาrenewปลายทางทันทีถ้ามันคืน 200 โทเค็นจะถูกรีเฟรช แต่ถ้าrenewกลับ 401 ก็หมายความว่าไคลเอนต์ออกจากระบบ คุณจะแนะนำทางเลือกใดจากสองข้อด้านบน อันไหนจะเป็นมาตรฐานมากขึ้นเข้าใจง่ายและ / หรือสงบมากขึ้น? หรือคุณจะแนะนำวิธีการอื่นโดยสิ้นเชิง? คุณเห็นปัญหาที่ชัดเจนหรือความเสี่ยงด้านความปลอดภัยที่มีตัวเลือกอย่างใดอย่างหนึ่ง? …

17 design  rest  web-services  http  authentication 

หากแอปพลิเคชันเปิดWebSocketฟีดสดอยู่แล้วฉันควรใช้แอปพลิเคชันนั้นAJAXเพื่อการสื่อสารอื่น ๆ กับเซิร์ฟเวอร์หรือไม่ เนื่องจากการเชื่อมต่อเปิดอยู่แล้วเราควรใช้สำหรับการร้องขอที่Request/Responseไม่ใช่แบบเรียลไทม์หรือไม่ ฉันชอบRESTful HTTPคำขอมากกว่าเพราะฉันพบข้อผิดพลาดได้ง่ายกว่า คุณสามารถใช้เบราว์เซอร์ที่มี URL หรือหยิกเพื่อทดสอบว่า API ส่งคืนอะไร WebSocketคุณไม่จำเป็นต้องเขียนโค้ดเพื่อเปิด มันจะแปลกที่จะมีRESTful HTTP APIและWebSocketในการประยุกต์ใช้กันได้หรือไม่

17 rest  ajax  websockets 

ฉันเจอการออกแบบการจัดหากิจกรรมและฉันต้องการใช้ในแอปพลิเคชันที่ต้องการให้ไคลเอ็นต์ REST (RESTful แม่นยำ) อย่างไรก็ตามฉันล้มเหลวในการเชื่อมต่อสิ่งเหล่านี้เข้าด้วยกันเนื่องจาก REST ค่อนข้างคล้ายกับ CRUD และการจัดหากิจกรรมเป็นงานที่ต้องทำ ฉันสงสัยว่าคุณจะออกแบบการสร้างคำสั่งตามคำขอไปยังเซิร์ฟเวอร์ REST ได้อย่างไร ลองพิจารณาตัวอย่างนี้: ด้วย REST คุณสามารถกำหนดสถานะใหม่ให้กับทรัพยากรที่เรียกว่าไฟล์ ในคำขอเดียวคุณสามารถส่งชื่อไฟล์ใหม่คุณสามารถเปลี่ยนโฟลเดอร์หลักและ / หรือเปลี่ยนเจ้าของไฟล์และอื่น ๆ วิธีสร้างเซิร์ฟเวอร์เพื่อให้ฉันสามารถใช้การจัดหากิจกรรมได้ ฉันคิดถึงความเป็นไปได้เหล่านี้: ตรวจสอบบนเซิร์ฟเวอร์ซึ่งสาขาที่มีการเปลี่ยนแปลงและสร้างคำสั่งที่เหมาะสม ( RenameFileCommand, MoveFileCommand, ChangeOwnerCommand, ... ) และจัดส่งเหล่านี้ที อย่างไรก็ตามในการตั้งค่านี้แต่ละคำสั่งสามารถล้มเหลวในการปล่อยให้ผู้อื่นออกจากการทำธุรกรรมและจากการเปลี่ยนแปลง "atomic" เป็นทรัพยากร ส่งเพียงหนึ่งคำสั่ง ( UpdateFileCommand) และในการจัดการคำสั่งอย่างแม่นยำมากขึ้นในการรวม, ตรวจสอบว่ามีการเปลี่ยนแปลงเขตและส่งแต่ละเหตุการณ์แทน ( FileRenamedEvent, FileMovedEvent, OwnerChangedEvent, ... ) อันนี้ฉันไม่ชอบเลย: ในคำขอไปยังเซิร์ฟเวอร์ฉันจะระบุในส่วนหัวของคำสั่งที่จะใช้เพราะ UI ยังคงเป็นงานที่ใช้ (การสื่อสารจะทำผ่าน REST) …

17 design  rest  event-sourcing 

เมื่อ API ต้องการให้ลูกค้ารับรองความถูกต้องฉันได้เห็นสถานการณ์ที่แตกต่างกันสองสถานการณ์ที่ใช้และฉันสงสัยว่ากรณีใดที่ฉันควรใช้กับสถานการณ์ของฉัน ตัวอย่าง 1. บริษัท ให้บริการ API เพื่ออนุญาตให้บุคคลที่สามรับรองความถูกต้องด้วยโทเค็นและข้อมูลลับโดยใช้ HTTP Basic ตัวอย่างที่ 2 API ยอมรับชื่อผู้ใช้และรหัสผ่านผ่าน HTTP Basic เพื่อตรวจสอบสิทธิ์ผู้ใช้ โดยทั่วไปแล้วพวกเขาจะได้รับโทเค็นกลับมาสำหรับคำขอในอนาคต การตั้งค่าของฉัน: ฉันจะมี JSON API ที่ฉันใช้เป็นแบ็กเอนด์สำหรับมือถือและเว็บแอป ดูเหมือนเป็นวิธีปฏิบัติที่ดีสำหรับทั้งแอปมือถือและเว็บในการส่งโทเค็นและความลับดังนั้นเฉพาะแอปทั้งสองนี้เท่านั้นที่สามารถเข้าถึง API ที่ปิดกั้นบุคคลที่สามอื่น ๆ แต่แอพมือถือและเว็บช่วยให้ผู้ใช้สามารถเข้าสู่ระบบและส่งโพสต์ดูข้อมูลของพวกเขาและอื่น ๆ ดังนั้นฉันต้องการให้พวกเขาเข้าสู่ระบบผ่านทาง HTTP พื้นฐานเช่นเดียวกับการร้องขอแต่ละครั้ง ฉันจะใช้ทั้งสองวิธีร่วมกันหรือส่งเฉพาะข้อมูลรับรองผู้ใช้ (ชื่อผู้ใช้และโทเค็น) ในแต่ละคำขอหรือไม่ หากฉันส่งเฉพาะข้อมูลรับรองผู้ใช้ฉันจะเก็บไว้ในคุกกี้บนไคลเอนต์หรือไม่

17 api  rest  authentication 

ฉันไม่เข้าใจถึงประโยชน์ของ HATEOAS สำหรับ API ที่ใช้สำหรับโปรแกรม (ตรงข้ามกับมนุษย์ที่เรียกดู API ของคุณโดยตรง) แน่นอนว่าลูกค้าไม่ได้ถูกผูกไว้กับสคีมา URL แต่พวกเขาจะถูกผูกไว้กับสคีมาข้อมูลซึ่งเป็นสิ่งเดียวกันในใจของฉัน ตัวอย่างเช่นสมมติว่าฉันต้องการดูรายการในคำสั่งซื้อสมมติว่าฉันได้ค้นพบหรือทราบ URL การสั่งซื้อแล้ว HATEOAS: order = get(orderURL); item = get(order.itemURL[5]); ไม่ใช่ HATEOAS: order = get(orderURL); item = get(getItemURL(order,5)); ในรุ่นแรกฉันต้องรู้ข้อเท็จจริงว่าวัตถุใบสั่งมีเขตข้อมูล itemURL ในรุ่นที่สองฉันต้องรู้วิธีสร้าง URL รายการ ในทั้งสองกรณีฉันต้อง "รู้" ก่อนล่วงหน้าดังนั้น HATEOAS ทำอะไรให้ฉันได้บ้าง

17 web-development  rest 

ฉันเพิ่งอ่านบทความนี้ที่มีอายุไม่กี่ปี แต่อธิบายวิธีที่ชาญฉลาดในการรักษา REST API ของคุณ เป็นหลัก: ลูกค้าแต่ละรายมีคู่คีย์สาธารณะ / ส่วนตัวที่ไม่ซ้ำกัน เฉพาะลูกค้าและเซิร์ฟเวอร์เท่านั้นที่รู้รหัสส่วนตัว มันไม่เคยถูกส่งผ่านสาย ด้วยการร้องขอแต่ละครั้งไคลเอนต์ใช้หลายอินพุต (การร้องขอทั้งหมดเองการประทับเวลาปัจจุบันและคีย์ส่วนตัว) และเรียกใช้ผ่านฟังก์ชัน HMAC เพื่อสร้างแฮชของการร้องขอ จากนั้นไคลเอ็นต์จะส่งคำขอปกติ (ซึ่งมีรหัสสาธารณะ) และแฮชไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์ค้นหาคีย์ส่วนตัวของลูกค้า (ตามคีย์สาธารณะที่ให้ไว้) และทำการตรวจสอบเวลาบางอย่าง (ที่ยอมรับกันโดยทั่วไปว่าฉันไม่เข้าใจ) ที่ยืนยันว่าคำขอไม่ตกเป็นเหยื่อของการโจมตีซ้ำ ถ้าทุกอย่างเรียบร้อยแล้วเซิร์ฟเวอร์จะใช้ไพรเวตคีย์และฟังก์ชั่น HMAC เดียวกันเพื่อสร้างการแฮชของคำขอ เซิร์ฟเวอร์จะเปรียบเทียบแฮชทั้งสอง (อันที่ส่งโดยลูกค้าเช่นเดียวกับที่สร้างขึ้น); หากตรงกันจะมีการตรวจสอบความถูกต้องและอนุญาตให้ดำเนินการต่อได้ จากนั้นฉันสะดุดJWTซึ่งฟังดูคล้ายกันมาก อย่างไรก็ตามบทความแรกไม่ได้พูดถึง JWT เลยและฉันก็สงสัยว่า JWT นั้นแตกต่างจากวิธีแก้ปัญหาข้างต้นหรือไม่และถ้าเป็นเช่นนั้น

16 security  rest  authentication  keys  hmac 

ประสิทธิภาพที่รวดเร็วกว่าคืออะไร การสร้าง REST API และการมีเว็บแอปของคุณใช้ REST API เพื่อทำการโต้ตอบกับฐานข้อมูลของคุณหรือทำการสืบค้นฐานข้อมูลของคุณโดยตรง (เช่นการใช้วัตถุทั่วไปที่ภาษาของคุณใช้ในการสืบค้นฐานข้อมูลเช่น JDBC for Java)? วิธีที่ฉันเห็นด้วย REST: คุณสร้างวัตถุในรหัสของคุณเพื่อเรียกใช้วิธีการ REST โทรวิธี http รหัสภายใน REST API ของคุณจะค้นหาฐานข้อมูล ฐานข้อมูลส่งคืนข้อมูลบางส่วน รหัส REST API จะแพ็คข้อมูลลงใน Json และส่งไปยังลูกค้าของคุณ ลูกค้าได้รับการตอบสนอง Json / XML แมปการตอบสนองกับวัตถุในรหัสของคุณ ในทางตรงกันข้ามการสืบค้นฐานข้อมูลโดยตรง: คุณทำวัตถุด้วยสายอักขระแบบสอบถามเพื่อสอบถามฐานข้อมูล ฐานข้อมูลส่งคืนข้อมูลบางส่วน แมปการตอบสนองกับวัตถุในรหัสของคุณ ดังนั้นนี่ไม่ได้หมายความว่าการใช้ REST API จะช้าลงหรือไม่ อาจขึ้นอยู่กับประเภทของฐานข้อมูล (SQL กับ NoSQL)?

16 database  rest  sql 

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

16 api  rest  http 

ฉันยังใหม่กับการทดสอบหน่วยฉันมีวิธีการทางเว็บที่เหลือเพียงแค่เรียก DB และเติมข้อมูล DTO รหัสหลอกคือ public object GetCustomer(int id) { CustomerDTO objCust = //get from DB return objCust; } ข้อสงสัยของฉันคือวิธีการเขียนการทดสอบสำหรับวิธีการเหล่านี้และประเภทของการทดสอบ (Integration / Unit) ที่จะรวม และสำหรับการทดสอบหน่วยจำเป็นต้องกดฐานข้อมูลหรือไม่ หากเป็นและฉันส่งรหัสลูกค้าและยืนยันน้อยข้อมูลอาจเปลี่ยนแปลงได้ในที่สุดทำให้เกิดความล้มเหลว ฉันคิดว่าฉันขาดอะไรบางอย่างที่นี่เพื่อทำความเข้าใจแนวคิดเหล่านี้

16 testing  unit-testing  rest  integration-tests 

ฉันมีสองแหล่งข้อมูล: ผู้ใช้และลิงก์ ผู้ใช้สามารถมีหลายลิงค์ที่เกี่ยวข้อง ฉันได้ออกแบบ RESTful API ของฉันเพื่อให้คุณสามารถเข้าถึงลิงก์ที่เกี่ยวข้องกับผู้ใช้ได้ที่ URI ต่อไปนี้: /users/:id/links อย่างไรก็ตามฉันจำเป็นต้องมี URI เสมอสำหรับลิงก์ - บางครั้งฉันอาจต้องการลิงก์ทั้งหมดโดยไม่คำนึงถึงผู้ใช้ สำหรับสิ่งนี้ฉันมี: /links เสียงนี้ใช้ได้ไหม? มี URI สองตัวสำหรับลิงก์หรือไม่ ฉันสงสัยว่าฉันควรเข้าถึงลิงก์สำหรับผู้ใช้ที่มี URI หรือไม่เช่น: /links/user/:id หรือ /links/?user=:id ด้วยวิธีนี้ฉันมีแหล่งข้อมูลเพียงแหล่งเดียวสำหรับลิงก์

16 api  rest  api-design 

ฉันมีการพิมพ์เพื่อดำเนินการกับเอกสารลูกค้าของฉัน ฉันต้องการการดำเนินการมาตรฐานอื่น ๆ ที่จะดำเนินการเช่นกันเช่นเพิ่มอัปเดตลบ ดังนั้นฉันมีดังต่อไปนี้: สำหรับการสร้างลูกค้าใหม่: URI = / customer / {id} ให้พิมพ์ = POST, Methodname = CreateCustomer () สำหรับการอัพเดต: URI: / customer / {id} ให้พิมพ์ = PUT, method = UpdateCstomer () สำหรับลบลูกค้า: URI = / customer / {id} ให้พิมพ์ = DELETE, Methodname = DeleteCustomer () สำหรับมุมมอง: URI: / customer …

16 rest 

ฉันกำลังใช้บริการเว็บสงบและแอปพลิเคชันไคลเอนต์หลายแห่งที่ส่วนใหญ่อยู่ใน Silverlight ฉันกำลังค้นหาตัวเลือกจำนวนมากสำหรับการพัฒนาทั้งฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ของ API แต่ไม่แน่ใจว่าวิธีใดดีที่สุด ฉันกังวลเกี่ยวกับความเสถียรเช่นเดียวกับแพลตฟอร์มที่จะยังคงมีอยู่ไม่กี่เดือนนับจากนี้ เราเริ่มใช้ REST Starter Kit กับ. NET 3.5 แต่ย้ายไปที่ WCF Web API ใหม่เมื่ออัปเดตเป็น. NET 4.0 เอกสารทั้งหมดของพวกเขาบ่งชี้ว่า WCF Web API เป็นการแทนที่สำหรับ RSK อย่างไรก็ตาม Web API อยู่ในหน้าตัวอย่าง 4 เท่านั้นและไม่รวมการสนับสนุนสำหรับ Silverlight หรือไคลเอนต์ Windows Phone 7 (ยัง) WCF Web API ดูเหมือน wrapper ด้านบนของ WCF WebHttp Services ที่มีอยู่ในSystem.ServiceModel.Webไลบรารีซึ่งทำให้ฉันคิดว่ามันอาจจะง่ายกว่าที่จะไปกับสิ่งที่มีอยู่ในตัว แต่ Web …

16 .net  rest  wcf 

เมื่ออ่านเกี่ยวกับ API เกตเวย์สิ่งหนึ่งที่เกิดขึ้นทุกครั้งคือ API เกตเวย์เป็นสถานที่ที่คุณควรรวมผลลัพธ์จากจุดปลายหลายจุด ฟังดูดีจริงๆ อย่างไรก็ตามโซลูชันเกตเวย์ API ยอดนิยมจำนวนมากเช่น AWS API Gateway, Kongo และ Netflix Zuul ไม่สนับสนุนคุณสมบัติดังกล่าว คุณต้องแฮ็คหรือใช้ตัวกรองที่กำหนดเองได้ การรวมตัวกันถือว่าเป็นการปฏิบัติที่ไม่ดีหรือไม่? ผู้คนส่งคืนผลลัพธ์จากหลายจุดสิ้นสุดได้อย่างไร

16 rest  api  microservices 

ฉันกำลังเริ่มโครงการใหม่เร็ว ๆ นี้ซึ่งกำหนดเป้าหมายแอปพลิเคชันมือถือสำหรับแพลตฟอร์มมือถือที่สำคัญทั้งหมด (iOS, Android, Windows) มันจะเป็นสถาปัตยกรรมไคลเอนต์เซิร์ฟเวอร์ แอพนี้เป็นทั้งข้อมูลและธุรกรรม สำหรับส่วนการทำธุรกรรมพวกเขาจะต้องมีบัญชีและเข้าสู่ระบบก่อนที่จะสามารถทำธุรกรรมได้ ฉันยังใหม่ต่อการพัฒนาอุปกรณ์พกพาดังนั้นฉันจึงไม่ทราบว่าส่วนการรับรองความถูกต้องจะทำอย่างไรบนแพลตฟอร์มเหล่านี้ ลูกค้าจะสื่อสารกับเซิร์ฟเวอร์ผ่าน REST API จะใช้หลักสูตร HTTPS ฉันยังไม่ได้ตัดสินใจว่าต้องการให้ผู้ใช้เข้าสู่ระบบเมื่อพวกเขาเปิดแอพหรือเมื่อพวกเขาทำธุรกรรม ฉันได้รับคำถามต่อไปนี้: 1) เช่นเดียวกับแอปพลิเคชั่น Facebook คุณจะป้อนข้อมูลรับรองของคุณเมื่อคุณเปิดแอปพลิเคชั่นเป็นครั้งแรกเท่านั้น หลังจากนั้นคุณจะลงชื่อเข้าใช้อัตโนมัติทุกครั้งที่คุณเปิดแอพ เราจะทำสิ่งนี้ให้สำเร็จได้อย่างไร? เพียงแค่เข้ารหัสและจัดเก็บข้อมูลรับรองบนอุปกรณ์และส่งทุกครั้งที่แอปเริ่มทำงาน 2) ฉันต้องพิสูจน์ตัวตนผู้ใช้สำหรับคำขอ (ธุรกรรม) ที่ทำกับ REST API หรือใช้วิธีตามโทเค็นหรือไม่? โปรดแนะนำวิธีอื่น ๆ ในการตรวจสอบสิทธิ์ ขอบคุณ!

16 rest  authentication  mobile