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

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

9 architecture  rest  enterprise-architecture  microservices  coupling 

ใช้จุดปลาย HTTP API ซึ่งพ่นรูปแบบการตอบสนองต่อไปนี้: { "type": "Dog", "name": "Jessi", ... } typeข้อมูลได้รับการอธิบายไว้ในเอกสารที่เป็นหนึ่งDog, หรือCatFish การเพิ่มตัวเลือกใหม่Ratจะถือว่าเป็นการเปลี่ยนแปลง API ที่ผิดปกติหรือไม่ การเพิ่มตัวเลือกในรายการที่ จำกัด (ซึ่งนักพัฒนาซอฟต์แวร์อาจเปิดใช้งาน) ถือว่าเป็นส่วนขยายหรือการแก้ไข API หรือไม่

9 rest  api  api-design  json 

ข้อมูลจำเพาะ JWT อธิบายถึงน้ำหนักบรรทุกและวิธีการส่ง แต่ปล่อยให้โปรโตคอลการตรวจสอบความถูกต้องเปิดซึ่งช่วยให้มีความยืดหยุ่น แต่น่าเสียดายที่ความยืดหยุ่นสามารถนำไปสู่การออกแบบและออกแบบที่ผิด ฉันกำลังมองหาแนวคิดที่ดีและผ่านการทดสอบการใช้งานองค์กรสำหรับการรับรองความถูกต้อง JWT ซึ่งฉันสามารถใช้หรือปรับเปลี่ยนได้ แต่ฉันล้มเหลวในการค้นหาสิ่งที่สมบูรณ์ สิ่งที่ฉันคิดคือ เมื่อไม่พบส่วนหัวการให้สิทธิ์หรือโทเค็น JWT ไม่ถูกต้องหรือหมดอายุให้ส่ง HTTP 401 เพื่อตรวจสอบสิทธิ์ใช้ / ล็อกอินช่อง REST ส่งชื่อผู้ใช้และรหัสผ่านเป็นวัตถุ JSON เพื่อให้โทเค็นยังมีชีวิตอยู่ใช้ / keepalive REST ช่องเรียกมันทุก ๆ N (5) นาทีรับโทเค็น JWT ใหม่และแทนที่หนึ่งที่มีอยู่หลังจากแต่ละสาย (โทเค็นหมดอายุหลังจาก M (15) นาที) อย่างไรก็ตามสิ่งที่รบกวนฉันคือความจำเป็นของช่องทางนั้น / keepalive ในทางกลับกันมันบังคับให้ฉันเพื่อป้องกันไม่ให้การรับรองความถูกต้องหมดอายุแม้ว่าผู้ใช้จะไม่อยู่ (การตัดสินใจถ้าเรายังต้องการ keepalive ยังไม่พบ) และแน่นอนการโทรเหล่านั้นเป็นพิเศษและมีความซับซ้อนเป็นพิเศษในโปรโตคอล สิ่งที่น่าสนใจก็คือเซิร์ฟเวอร์นั้นจะขยายโทเค็นโดยอัตโนมัติ ในสภาพแวดล้อมแบบเซสชันนั้นเกิดขึ้นโดยการรีเซ็ตเวลาประทับที่นี่อย่างไรก็ตามเซิร์ฟเวอร์จะต้องส่งโทเค็นใหม่อาจไม่ได้แต่ละครั้ง แต่เมื่อโทเค็นจะหมดอายุใน R (พูด 10 …

9 rest  authentication  architectural-patterns 

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

9 rest  api  api-design 

ฉันมี REST API สำหรับ entpoinds บางตัวเช่น DELETE, POST หรือ PUT ฉันมีกฎการตรวจสอบที่สามารถส่งคืนข้อผิดพลาดได้ ตอนนี้ฉันต้องการข้อผิดพลาดชนิดใหม่เช่นข้อผิดพลาดที่ไม่ร้ายแรงว่าควรล้มเหลวในลักษณะปกติ แต่ควรดำเนินการหากมีการส่งแฟล็ก "supress warnings" ผู้ใช้ดังกล่าวสามารถถาม: "คุณแน่ใจหรือว่าต้องการเปลี่ยนสถานะนี้คุณยังไม่เสร็จ" คำถาม : มีวิธีปฏิบัติที่ดีที่สุดสำหรับข้อผิดพลาดประเภทนี้หรือไม่? คำถามรอง : มี HTTP semantic ใด ๆ สำหรับพฤติกรรมที่ฉันสามารถใช้หรือไม่ ฉันจะยังคงทำตามแนวคิด REST (สำหรับฉันแล้วดูเหมือนว่าฉันจะทำ) - ฉันเก็บมันไว้ไร้สัญชาติ

9 rest  api 

บริบท เนื่องจากความไร้สัญชาติของรูปแบบสถาปัตยกรรม REST ที่เกี่ยวข้องกับการร้องขอแต่ละรายการนั้นล้วน แต่อยู่คนเดียวเซิร์ฟเวอร์ชั้นนำที่จะไม่เก็บข้อมูลใด ๆ เกี่ยวกับลูกค้า ดังนั้นการควบคุมภาวะพร้อมกันในแง่ร้ายไม่เหมาะสมเพราะจะต้องมีการจัดเก็บเซิร์ฟเวอร์ที่ลูกค้าจะได้รับการล็อคทรัพยากร การควบคุมภาวะพร้อมกันในแง่ดีนั้นจะถูกนำมาใช้ด้วยความช่วยเหลือของEtagส่วนหัว (btw ตามที่ฉันถาม/programming/30080634/concurrency-in-a-rest-api ) ปัญหา ปัญหาหลักที่เกิดขึ้นกับกลไกการควบคุมภาวะพร้อมกันในแง่ดีคือคุณอนุญาตให้ลูกค้าทุกคนทำการดำเนินการใด ๆ ได้ตลอดเวลา และฉันต้องการหลีกเลี่ยงสิ่งนั้นโดยไม่ทำลายหลักการไร้สัญชาติของ REST ฉันหมายความว่าลูกค้าทั้งหมดไม่สามารถดำเนินการใด ๆ ได้ตลอดเวลา คำถาม ในใจของฉันมันเป็นไปได้ด้วยกลไกการควบคุมภาวะพร้อมกันแบบกึ่งมองโลกในแง่ดีเช่นนั้น: ลูกค้าสามารถขอโทเค็น สามารถสร้างโทเค็นเดียวเท่านั้นและมีระยะเวลาที่ จำกัด หากต้องการดำเนินการกับทรัพยากร (เช่นPOSTหรือPUT ) ไคลเอ็นต์จะต้องให้โทเค็นนี้เป็นส่วนหนึ่งของเนื้อความ (หรือส่วนหัว?) ของคำขอ ลูกค้าที่ไม่มีโทเค็นไม่สามารถทำการดำเนินการเหล่านี้ได้ มันคล้ายกันมากกับการควบคุมภาวะพร้อมกันในแง่ดียกเว้นว่ามีลูกค้าเพียงรายเดียวเท่านั้นที่สามารถทำการดำเนินการบางอย่าง (ลูกค้าที่ได้รับโทเค็น) ... ตรงข้ามกับ "ลูกค้าทุกคนสามารถดำเนินการทั้งหมดได้" กลไกนี้เข้ากันได้กับสไตล์สถาปัตยกรรม REST หรือไม่? มันทำลายข้อ จำกัด ใด ๆ หรือไม่? ฉันคิดว่าจะถาม SO แต่ดูเหมือนว่าจะเป็นคำถามระดับสูงที่เกี่ยวข้องกับการออกแบบซอฟต์แวร์

9 design  architecture  rest  concurrency 

ฉันต้องการสร้างประวัติการเลิกทำเมื่อใดก็ตามที่ผู้ใช้อัปเดตฟอร์ม เนื่องจากเป็นการอัปเดตฉันต้องการใช้คำขอ PUT แต่ผมอ่านที่ความต้องการนำไปไม่มีผลข้างเคียง เป็นที่ยอมรับหรือไม่ที่จะใช้ PUT ที่นี่ มีทางเลือกที่ดีกว่านี้ไหม? PUT /person/F02E395A235 { time: 1234567, fields: { name: 'John', age: '41' } } ในเซิร์ฟเวอร์ doPut('person/:personId', // create a new person snapshot ) แก้ไข: ผู้ใช้จะสามารถเห็นประวัติได้การเรียกหลายครั้งจะทำให้หลายเวอร์ชัน วิธีแก้ไขคือการตรวจสอบว่าเป็นรุ่นที่ไม่ซ้ำกันก่อนที่จะสร้างมัน

9 language-agnostic  api  rest 

ในการเปรียบเทียบ REST [api] โครงสร้างกับโมเดล OO ฉันเห็นความคล้ายคลึงกันเหล่านี้: ทั้งสอง: กำลังมุ่งเน้นข้อมูล REST = ทรัพยากร OO = วัตถุ ล้อมรอบการดำเนินงานรอบข้อมูล REST = ล้อมรอบ VERBS (รับ, โพสต์, ... ) รอบ ๆ แหล่งข้อมูล OO = ส่งเสริมการดำเนินการรอบ ๆ วัตถุโดยห่อหุ้ม อย่างไรก็ตามแนวปฏิบัติที่ดีของ OO นั้นไม่ได้อยู่บน REST apis เสมอเมื่อพยายามใช้รูปแบบซุ้มเช่นใน REST คุณไม่มีตัวควบคุม 1 ตัวที่จะจัดการกับคำร้องขอทั้งหมดและคุณจะไม่ซ่อนความซับซ้อนของวัตถุภายใน ในทางตรงกันข้าม REST ส่งเสริมการเผยแพร่ทรัพยากรของความสัมพันธ์ทั้งหมดกับทรัพยากรและอื่น ๆ ในรูปแบบอย่างน้อยสองรูปแบบ: ผ่านความสัมพันธ์ลำดับชั้นของทรัพยากร (ผู้ติดต่อของ id 43 …

9 http  rest  definition 

ฉันออกแบบ API REST สำหรับระบบสามชั้นเช่น: Client application-> ->Front-end API cloud serveruser's home API server (Home) Homeเป็นอุปกรณ์บ้านและควรจะรักษาเชื่อมต่อFront-endผ่าน WebSocket หรือโพลล์ยาว(นี้เป็นสถานที่แรกที่เรากำลังละเมิด REST. จะได้รับก็แย่ภายหลัง) Front-endช่องสัญญาณส่วนใหญ่Clientร้องขอการHomeเชื่อมต่อและจัดการการโทรบางตัว บางครั้งส่งการแจ้งเตือนไปยังHomeClient Front-endและHomeมี API เดียวกันโดยทั่วไป Clientอาจเชื่อมต่อHomeโดยตรงผ่าน LAN ในกรณีนี้Homeจำเป็นต้องลงทะเบียนClientการกระทำบางอย่างกับFront-endตัวเอง ข้อดีสำหรับ REST ในระบบนี้คือ: REST สามารถอ่านได้โดยมนุษย์ ส่วนที่เหลือมีการทำแผนที่กริยาที่กำหนดไว้อย่างดี (เช่น CRUD) คำนามและรหัสการตอบสนองกับวัตถุโปรโตคอล; มันทำงานผ่าน HTTP และส่งผ่านผู้รับมอบฉันทะที่เป็นไปได้ทั้งหมด; ส่วนที่เหลือ REST คือ: เราไม่เพียง แต่ต้องการสไตล์การสื่อสารที่ตอบสนองการร้องขอเท่านั้น รหัสข้อผิดพลาด HTTP อาจไม่เพียงพอสำหรับจัดการข้อผิดพลาดการสื่อสารสามระดับ Front-endอาจจะกลับ202 Acceptedไปโทร async …

9 architecture  web-services  rest  message-queue  websockets 

ขณะนี้เรากำลังออกแบบ REST API เพื่อเข้าถึงข้อมูลลูกค้าแบบดั้งเดิม หนึ่งในองค์ประกอบใน API เป็นสินทรัพย์ของผู้ใช้ สินทรัพย์จะถูกเพิ่มภายใต้บริการที่กำหนด API ส่วนหลังจะเพิ่มเนื้อหาให้กับผู้ใช้ภายใต้บริการที่กำหนดเท่านั้น ดังนั้นจึงไม่มีผู้ใช้ - ความสัมพันธ์ของเนื้อหา แต่เป็นผู้ใช้ - [บริการ] - ความสัมพันธ์ของเนื้อหา URI ของเราจะเป็นดังนี้: /users/{id}/assets/{id}/services/{id} การใช้ API จะทราบรหัสเนื้อหาและรหัสบริการเพื่อสร้างรายการใหม่ สิ่งที่เราดิ้นรนคือการสร้างความสัมพันธ์นี้ วิธีหนึ่งที่ตรงไปตรงมาคือการโพสต์ความสัมพันธ์ทั้งหมด /users/{id}/assets/ POST /users/{id}/assets {asset:${id}, service:{id}, attribute1:"{var}", attribute2:"{var}"} แต่จากนั้นเราไม่ได้สร้างเนื้อหาตามที่ URI อาจระบุ แต่เป็นเรื่องเกี่ยวกับบริการสินทรัพย์ อีกทางเลือกหนึ่งเรากำลังพิจารณา POST'ing กับ URI ที่เกี่ยวข้องกับความสัมพันธ์ดังนี้: POST /users/{id}/assets/{id}/service/{id} {attribute1:"{var}", attribute2:"{var}"} แต่ในกรณีนี้เส้นทางของทรัพยากร/users/{id}/assets/{id}จะไม่มีอยู่ก่อน POST และจะถูกสร้างเป็นผลข้างเคียง กำลังโพสต์ไปยังเส้นทางของทรัพยากรที่ยังไม่ได้รับอนุญาตเลย? …

9 design  design-patterns  rest 

เรามีโครงการที่รหัส UI จะได้รับการพัฒนาโดยทีมเดียวกัน แต่ในภาษาอื่น (Python / Django) จากชั้นบริการ (REST / Java) รหัสสำหรับแต่ละชั้นออกจากที่เก็บรหัสที่แตกต่างกันและสามารถติดตามรอบการเปิดตัวที่แตกต่างกัน ฉันพยายามหากระบวนการที่จะป้องกัน / ลดการเปลี่ยนแปลงในเลเยอร์บริการจากมุมมองของเลเยอร์ UI ฉันคิดว่าจะเขียนการทดสอบการรวมที่ระดับเลเยอร์ UI ที่เราจะเรียกใช้เมื่อใดก็ตามที่เราสร้าง UI หรือเลเยอร์บริการ (เรากำลังใช้ Jenkins เป็นเครื่องมือ CI ของเราในการสร้างรหัสซึ่งอยู่ใน repos Git สอง) และถ้า มีความล้มเหลวดังนั้นบางสิ่งในเลเยอร์บริการแตกและการยอมรับไม่ยอมรับ มันจะเป็นความคิดที่ดี (มันเป็นวิธีปฏิบัติที่ดีที่สุดหรือไม่) เพื่อให้ผู้พัฒนาเลเยอร์บริการสร้างและบำรุงรักษาไลบรารีไคลเอ็นต์สำหรับบริการ REST ที่มีอยู่ในเลเยอร์ UI ที่พวกเขาจะอัปเดตเมื่อใดก็ตามที่มีการเปลี่ยนแปลง Service API ของพวกเขา น่าจะเป็นไปได้ว่าเราจะได้ประโยชน์จาก API ที่พิมพ์แบบคงที่ซึ่งรหัส UI นั้นสร้างขึ้นมา หาก API ของไลบรารีไคลเอ็นต์เปลี่ยนแปลงรหัส UI …

9 rest  django 

นี่คือสิ่งที่ฉันคิดเกี่ยวกับการทำบนเซิร์ฟเวอร์ JEE Glassfish โดยใช้ Jersey @GET @Path("/{name}/{date}") public String getMessages(@PathParam("name") String name, @PathParam("date") Date date) ฉันชอบความคิดที่จะบอกผู้คนที่ใช้บริการเว็บ RESTful นี้ว่า "วันที่นี่คือทุกอย่างที่ทำงานกับคลาส Date ใน Java" นั่นง่ายมากจากมุมมองที่พวกเขาสามารถดูข้อมูลจำเพาะของวันที่และพวกเขาจะมีรูปแบบการทำงานที่สามารถทดสอบได้แล้ว ปัญหาที่ฉันกังวลคือเมื่อฉันทำสิ่งนี้ JAX-RS ไม่ค่อยดีนักเมื่อ Date () ไม่ชอบสิ่งที่ได้รับในตัวสร้าง เนื่องจาก Date () ส่งข้อผิดพลาดหากไม่สามารถแยกวิเคราะห์สิ่งที่ได้รับ (เช่นถ้าคุณส่งสตริง "วันนี้" แทนที่จะเป็นวันที่จริง) เซิร์ฟเวอร์ JEE จะส่งกลับข้อผิดพลาด 404 นี่เป็นวิธีปฏิบัติที่ดีหรือไม่? มีวิธีที่ดีกว่าในการทำสิ่งนี้ที่ฉันไม่ได้คิด?

9 rest  date-format 

เรากำลังออกแบบ RESTful API เพื่อเปิดข้อมูลบัญชีลูกค้าของเรา เรามีตัวแทนที่มีการอ้างอิงถึงทรัพยากรอื่น ๆ ที่เกี่ยวข้องกับทรัพยากรปัจจุบัน นี่เป็นวิธีปฏิบัติที่ดีที่สุดหลายประการที่เราพบได้ใน API สาธารณะและวัสดุที่เผยแพร่ การเป็นตัวแทนสามารถเป็น XML หรือ JSON ตัวอย่างเช่นสำหรับทรัพยากรบัญชีเราจะมีการอ้างอิงไปยังที่อยู่ของบัญชีและสำหรับรายการทรัพยากรที่มีเลขหน้าเราจะมีการอ้างอิงไปยังหน้าแรกหน้าถัดไปและหน้าก่อนหน้า API ได้รับการออกแบบครั้งแรกโดยใช้ลิงก์ความหมาย<link title="" rel="" href="" />ตามที่อธิบายไว้ในหนังสือ O'Reilly และใช้ใน APIs โดย Netflix และ Google เมื่อถึงเวลาสำหรับวิศวกรควบคุมคุณภาพของเราที่จะเขียนชุดระบบอัตโนมัติพวกเขามีปัญหาในการยกเลิกการเชื่อมโยง ตอนนี้เราได้แนะนำองค์ประกอบสตริง uri ที่เรียบง่ายซึ่งใช้ใน API โดย Facebook และ Twitter ผู้ชำนาญการควบคุมคุณภาพของเราได้แก้ไขปัญหา deserialization ของพวกเขาแล้ว แต่ฉันยังคงมีความกังวลเกี่ยวกับความง่ายในการใช้งานของข้อมูลจำเพาะ API ปัจจุบันที่มีการเชื่อมโยงความหมาย API ของเราส่วนใหญ่จะถูกใช้โดยลูกค้าของเราและพันธมิตรบุคคลที่สามบางส่วนและเราได้ไปที่ REST เนื่องจาก XML-RPC API ก่อนหน้านี้เป็นเรื่องยากสำหรับผู้บริโภคของเรา …

9 rest  semantics