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

ฉันค่อนข้างใหม่ในแง่ของทักษะการพัฒนาเว็บ Java ฉันมีโครงการที่ฉันคิดว่าจะทำให้ผู้สมัครที่ดีสำหรับบริการ RESTful จากสิ่งที่ฉันเข้าใจเกี่ยวกับ API น้อย ฉันพยายามที่จะดูรายละเอียดว่ามันควรจะมีโครงสร้างอย่างไร แต่ไม่ได้ไปที่ใดก็ได้ในแง่ของการค้นหาของ google และอ่านเนื้อหาที่ฉันมีอยู่แล้ว ฉันหวังว่าโพสต์นี้จะให้การตรวจสอบและ / หรือการเปลี่ยนเส้นทางในแง่ของความรู้และสมมติฐานของฉันในหัวข้อนี้ ข้อสันนิษฐานปัจจุบันของฉันคือการให้บริการที่สงบของฉันจะมีโครงสร้างดังต่อไปนี้: ข้อมูลฐานข้อมูล (SQL) ORM (ฉันใช้ ORM ที่ค่อนข้างไม่เป็นที่นิยมเรียกว่า CPO แต่สิ่งนี้จะถูกแทนที่ด้วย Hibernate กับคนส่วนใหญ่) คลาสผู้จัดการ Java ด้วยวิธีการที่พูดคุยกับ ORM เพื่อรับข้อมูล คลาสตัวควบคุม Java / คลาสที่จัดการการแมปคำขอและใช้@ResponseBodyเพื่อกำหนด / จัดการ URL และการกระทำของวิธีการจัดการข้อมูลผ่านทางคำกริยา HTTP ( http://mysite.com/computers/dellอาจมีการGETร้องขอด้วยคำว่า "dell" ใน URL เป็นพารามิเตอร์ที่จะส่งคืนอาร์เรย์ของข้อมูล JSON เกี่ยวกับคอมพิวเตอร์เดลล์) บริการนี้ควรทำด้วย Spring Boot …

12 java  web-applications  rest  api  spring 

ตัวอย่างเช่นฉันมีเอนทิตี: ลูกค้า, รายงาน ลูกค้าอาจมีหลายรายงานและฉันคิดว่าจุดสิ้นสุดสำหรับการจัดการรายงานเดียวควรซ้อนกันเช่นนี้ /clients/{client_id}/reports/{report_id} สำหรับรายงานทั้งหมดของลูกค้าหนึ่งรายคาดว่าจะเป็น enpoint: /clients/{client_id}/reports แต่ควรมองหาจุดสิ้นสุดเพื่อให้ได้รับรายงานทั้งหมดของลูกค้าทั้งหมดเพื่อให้ API มีความสอดคล้องและได้รับการออกแบบมาเป็นอย่างดี แนวทางของฉัน: (ฉันเห็นมันในบาง google api) ใช้ "-" แทนและแยกเป็น "ทั้งหมด": /clients/-/reports สิ่งนี้คงรูปแบบจุดปลายเหมือนกัน แต่ดูผิดปกติเล็กน้อยไม่พบ rfc ใด ๆ ที่แนะนำวิธีนี้ สร้างจุดปลายแยกเฉพาะสำหรับรายงานทั้งหมด: /reports แต่เพื่อรับรายงานลูกค้าก็ยัง: /clients/{client_id}/reports Refactor endpoints เพื่อทำให้ "client" ไม่ใช่ parent แต่เป็นเพียงพารามิเตอร์ตัวกรอง: /reports?client={client_id} - รายงานลูกค้าหนึ่งราย /reports - รายงานของลูกค้าทั้งหมด ในกรณีของการเพิ่มจุดปลายใหม่สำหรับการโพสต์รายงานสำหรับลูกค้าที่เฉพาะเจาะจงมันอาจดูน่าเกลียดเพราะมันจะเป็นคำขอ POST กับพารามิเตอร์ใน URL มีคำแนะนำอื่น ๆ เกี่ยวกับความคิดหรือไม่?

12 rest  api  api-design 

นี่ทำให้ฉันงุนงงมาระยะหนึ่งแล้ว ตัวอย่างเช่นเรามี REST API ที่ให้เนื้อหาพื้นฐานไปยังระบบการบริโภคและการผลิต JSON ที่จุดสิ้นสุดนี้จะสร้าง URL ให้กับรูปภาพและคำอธิบายและพบได้ดังนี้: // localhost / myApi / pictures / 1 { id: 1, description: "This is a pretty picture of a daisy", URL: <OUR URL> } ตอนนี้ OUR_URL ควรชี้ไปที่ตำแหน่งบน API เช่น // localhost / myApi / files / pictures / 1 ซึ่งส่งคืน JPG …

12 rest  patterns-and-practices 

MVC ค่อนข้างตรงไปตรงมา มีรูปแบบตัวควบคุมและมุมมอง เมื่อเราสร้างเว็บไซต์มันทั้งหมดมารวมกันเป็น ' ไคลเอนต์ส่งคำขอคำหลัก REST ไปยังเซิร์ฟเวอร์ -> เซิร์ฟเวอร์ตรงกับ URL ที่ร้องขอไปยังการดำเนินการควบคุม -> ซึ่งจากนั้นเรียกรูปแบบ (s) สำหรับการรวบรวมข้อมูล / การประมวลผลได้รับผล -> และส่งคืนผลลัพธ์กลับไปยังลูกค้าเป็นหน้า HTML (ดู) ' ถ้าเรากำลังพูดถึง RESTful API เว็บเซอร์วิสอย่างแท้จริง จากนั้นโฟลว์ที่มีลักษณะคล้าย ' ไคลเอนต์จะส่งคำขอคำหลัก REST ไปยังเซิร์ฟเวอร์ -> เซิร์ฟเวอร์จับคู่ URL ที่ร้องขอไปยังแอ็คชั่นคอนโทรลเลอร์ -> ซึ่งจะเรียกโมเดลเพื่อรวบรวม / ประมวลผลข้อมูลรับผลลัพธ์ -> และส่งกลับ ผลลัพธ์กลับไปยังไคลเอ็นต์ใน JSON ' เหมือนเมื่อก่อน แต่ไม่มี 'มุมมอง' ... หรือมากกว่านั้น …

12 design-patterns  mvc  rest  api  api-design 

ปิด คำถามนี้ต้องการรายละเอียดหรือความคมชัด ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ เพิ่มรายละเอียดและชี้แจงปัญหาโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา บนหน้าเว็บของฉันหากฉันต้องการแสดงรายการแบบเลื่อนลงแบบไดนามิก (เช่นชื่อเมืองตามประเทศที่เลือก) ฉันสามารถทำได้โดยใช้ AJAX แต่ฉันสามารถทำได้โดยใช้การเรียกใช้ REST ฉันควรใช้อันไหนดี? ปัญหาของฉันคือฉันไม่ได้รับความแตกต่างระหว่างส่วนที่เหลือกับคำขอเบราว์เซอร์ HTTP อื่น ๆ (หรือที่เรียกว่าแบบฟอร์มส่ง) ฉันดูคำจำกัดความที่เป็นทางการของ REST และดูเหมือนว่าจะเป็นคำขอ HTTP REST แตกต่างจาก AJAX อย่างไร?

12 rest  ajax 

ฉันกำลังพัฒนาบริการใหม่ในสภาพแวดล้อมแบบไมโครเซอร์วิส นี่คือบริการ REST เพื่อความง่ายสมมติว่าเส้นทางคือ: / historyBooks และวิธีการ POST สำหรับเส้นทางนี้สร้างหนังสือประวัติศาสตร์ใหม่ สมมติว่าหนังสือประวัติศาสตร์ครอบคลุมยุคหนึ่งในประวัติศาสตร์ เพื่อความกระชับลองสมมุติว่าเรามีเพียงประวัติศาสตร์ยุคต่อไปนี้: โบราณ โพสต์คลาสสิก ทันสมัย enumในรหัสของฉันฉันต้องการที่จะเป็นตัวแทนของพวกเขาใน ร่างกายวิธีของ (น้ำหนักบรรทุก) อยู่ในรูปแบบ JSON erasและควรรวมถึงชื่อสนาม ฟิลด์นี้เป็นรายการeraค่าที่หนังสือเล่มนี้ครอบคลุม ร่างกายอาจมีลักษณะ: { "name": "From the cave to Einstein - a brief history review", "author": "Foo Bar", "eras": ["Ancient", "Post Classical", "Modern"] } ในบริการเฉพาะนี้ตรรกะทางธุรกิจคือ: หากไม่มียุคที่ระบุไว้ในข้อมูลเข้าดังนั้นหนังสือเล่มนี้จะถือว่าครอบคลุมทุกยุคทุกสมัย ในการตรวจสอบ API มีข้อเสนอแนะ: รวมค่าอื่นALLสำหรับยุค enum …

11 rest  api  json  enum 

เราจะสร้างระบบด้วย UI ใน javaFx ที่จะนำไปใช้กับเครื่องมากกว่า 2000 เครื่อง (ขั้นต่ำคือ 2000 แต่จะมีมากขึ้น - สามารถเข้าถึงเครื่องได้ 5,000 เครื่อง) ด้วยเหตุผล / ข้อ จำกัด อื่น ๆ จะต้องติดตั้งบนเครื่องดังนั้นเราจึงไม่สามารถทำได้ด้วยเว็บเบราว์เซอร์อินเตอร์เฟส เครื่องจักรกว่า 2,000 เครื่องจะอยู่ในกลุ่มที่ตั้งทางภูมิศาสตร์ที่แตกต่างกัน โดยทั่วไปแล้วการเชื่อมต่อนั้นดี แต่อาจไม่ดีในสถานที่ห่างไกล แทนที่จะเข้าถึงฐานข้อมูลโดยตรงฉันกำลังคิดถึงการสร้างคลัสเตอร์เซอร์วิส REST ด้วย Spring + Spring Boot + Spring Data (java) เซอร์วิส REST จะยอมรับและส่งคืน Json ฉันคิดว่ามันเป็นความคิดที่ดีเพราะ: บริการจะทำหน้าที่เป็นกลุ่มการเชื่อมต่อฐานข้อมูล (ฉันคิดว่าการเชื่อมต่อ 2000+ บนฐานข้อมูลอาจทำให้เกิดปัญหา); เป็นไปได้ที่จะมีฐานข้อมูลพร้อมบันทึกการจัดส่งไปยังฐานข้อมูลแบบอ่านอย่างเดียวอื่น ๆ มันจะขยายขนาดได้ดีขึ้นเนื่องจากเราสามารถเพิ่มเครื่องจักรให้ทำงานบริการ REST …

11 java  design  rest  spring 

ฉันพบปัญหาเดียวกันนี้ซ้ำแล้วซ้ำอีกและฉันไม่พบวิธีแก้ปัญหาที่ฉันรู้สึกว่าเหมาะสมที่สุด พูดในแอปคุณมีรายการที่สั่งซื้อและคุณให้ผู้ใช้เปลี่ยนลำดับนั้นโดยการลากและวางหรือบางอย่าง คุณต้องการให้การเปลี่ยนแปลงนั้นยังคงอยู่ คุณทำแบบนั้นอย่างไร ฉันจะออกแบบบริการพักผ่อนของทรัพยากรรายการที่สั่งซื้อได้อย่างไร โดยเฉพาะอย่างยิ่งฉันจะออกแบบlistและitemรูปแบบของทรัพยากรที่สงบได้อย่างไร การออกแบบที่พบบ่อยที่สุดที่ฉันเคยเห็นคือitemเอนทิตีที่มีorderหรือpositionคุณสมบัติ อีกวิธีที่ฉันได้ยินคือรายการที่เชื่อมโยงเป็นสองเท่าในรายการ อะไรคือวิธีการที่ไม่เขียนฐานข้อมูลมากเกินไปและโดยทั่วไปแล้วรวดเร็วในการอัพเดตและอ่านสำหรับลูกค้า? จุดสิ้นสุดควรถูกเปิดเผยอย่างไร

11 rest  database-design  data-structures  data-modeling 

ฉันพยายามแปลงชุดบริการที่ใช้ SOAP เป็น RESTful API Subscriptionผมเริ่มด้วยการระบุทรัพยากรโดยการวิเคราะห์ชื่อการดำเนินงานและผมได้ทรัพยากร เมื่อฉันต้องการอัปเดตสถานะการสมัครสมาชิกฉันไม่สามารถส่งPOSTคำขอไปยังเซิร์ฟเวอร์ได้เพราะฉันไม่สามารถเข้าถึงทรัพยากรได้โดยตรง แต่ฉันต้องเรียกการดำเนินงานสไตล์ RPC บางอย่างเพื่ออัปเดตคุณสมบัติของพวกเขา นอกจากนี้เฉพาะในกรณีที่ฉันเปลี่ยนสถานะของการสมัครเป็น "ใช้งานอยู่" ต้องทำการโทรเพิ่มเติมไปยังบริการภายนอก ในกรณีเหล่านี้แนวทางปฏิบัติที่ดีที่สุดในการจัดการการปฏิบัติงานพื้นฐานคืออะไร วิธีแก้ปัญหาที่ฉันพบคือการใช้พารามิเตอร์ข้อความค้นหาดังนั้นหากฉันต้องการเรียกใช้บริการการเปิดใช้งานฉันสามารถใช้สิ่งต่อไปนี้ POST /subscriptions/{subscriptionid}/?activate=true เมื่อพิจารณาว่าฉันไม่สามารถอัปเดตฟิลด์วัตถุการสมัครของฉันโดยตรงมีวิธีปฏิบัติที่ดีที่สุดในการจัดการการแปลงประเภทนี้หรือไม่ อัปเดต 1: ฉันสามารถใส่ค่า POST ลงในเนื้อหาได้เช่น "state": "active" และตรวจสอบภายในบริการของฉันการดำเนินการที่เหมาะสมที่จะถูกเรียก

11 rest  web-services  api-design  web-api 

ฉันกำลังสร้างเว็บแอปพลิเคชันและบริการเว็บสงบ ฉันได้อ่านบทความต่าง ๆ เกี่ยวกับวิธีที่ดีที่สุดในการรับรองความถูกต้องของคำขอไปยังบริการเว็บ ตัวเลือกที่ดีที่สุดสำหรับฉันดูเหมือนจะใช้การตรวจสอบสิทธิ์พื้นฐาน HTTP ค่อนข้างทุกบทความอ่าน ive กล่าวว่าการตรวจสอบควรเข้ารหัสผ่าน SSL หรือเทียบเท่า ฉันไม่แน่ใจว่าสิ่งนี้เกี่ยวข้องกับอะไรทั้งหมด นี่หมายความว่าบริการเว็บทั้งหมดของฉันจะต้องอยู่บนเซิร์ฟเวอร์ที่ปลอดภัยหรือไม่ สิ่งนี้จะช้าลงหรือไม่

11 web-services  rest  authentication  ssl  https 

ฉันทำงานกับ API สำหรับบริการ REST ที่ฉันจะผลิตและบริโภค ฉันใช้เวลาไม่กี่วันที่ผ่านมาพยายามหาวิธีจัดการกับการรับรองความถูกต้องอย่างดีและคิดว่าในที่สุดฉันก็คิดอะไรบางอย่าง ฉันกำลังทำสิ่งนี้ตามข้อเท็จจริงต่อไปนี้เกี่ยวกับสแต็กแอปพลิเคชัน: ไคลเอ็นต์ & เซิร์ฟเวอร์อยู่ใน. NET4 (ส่วนลูกค้าในโปรไฟล์ลูกค้า) เซิร์ฟเวอร์แสดงโดยใช้ WCF REST ฉันไม่ต้องการเก็บชื่อผู้ใช้และรหัสผ่านไว้ในหน่วยความจำในแอพ จาก 3 ฉันต้องการใช้รูปแบบการตรวจสอบความถูกต้องของโทเค็นเพื่อให้หลังจากที่ข้อมูลรับรองถูกตรวจสอบโดยเซิร์ฟเวอร์ลูกค้าจะได้รับโทเค็นกลับมาใช้ตลอดช่วงเวลาที่เหลือของแอป (สิ่งนี้จะทำให้ฉันทำสิ่งอื่น ๆ เช่น หมดเวลาผู้ใช้สามารถย้ายผู้ใช้อย่างต่อเนื่องระหว่างเว็บและเดสก์ท็อปเวอร์ชัน ฯลฯ ) หลังจากหาวิธีการโทรซ้ำและป้องกันการรบกวนฉันได้รับสิ่งต่อไปนี้: ก่อนที่ลูกค้าจะพยายามพิสูจน์ตัวตนมันจะสร้างคู่คีย์ Diffie-Hellman โดยใช้ECDiffieHellmanCngคลาส มันจะส่งส่วนสาธารณะของคู่กุญแจผ่านสายพร้อมกับชื่อผู้ใช้และรหัสผ่าน (ผ่าน HTTPS แน่นอน) เซิร์ฟเวอร์รับรองความถูกต้องของชื่อผู้ใช้ / รหัสผ่านหากทำสำเร็จจะทำสิ่งต่อไปนี้: สร้างโทเค็นเซสชันที่ไม่ซ้ำกัน สร้างคู่คีย์ DH ของตนเองและคำนวณความลับที่ใช้ร่วมกันจากพับลิกคีย์ที่ลูกค้าให้ไว้ บันทึกโทเค็นเซสชันความลับที่ใช้ร่วมกันผู้ใช้และเวลา "การกระทำล่าสุด" (ใช้สำหรับหน้าต่างหมดอายุการหมุน) ในฐานข้อมูล ส่งคืนโทเค็นเซสชันคีย์สาธารณะ DH และข้อความยืนยันความสำเร็จในการตรวจสอบความถูกต้อง ไคลเอ็นต์ใช้คีย์ DH จากการตอบสนองคำนวณความลับที่ใช้ร่วมกันและเก็บทั้งโทเค็นและความลับในหน่วยความจำ …

11 algorithms  rest  authentication 

ทั้งหมดนี้อาจเจอสิ่งที่แปลกใหม่มาก แต่ฉันพยายามคาดเดาการออกแบบเว็บไซต์ที่สงบเรียบร้อย ฉันเข้าใจการใช้การออกแบบ RESTful กับสิ่งต่าง ๆ เช่นผู้ใช้รูปภาพโพสต์บล็อก ฯลฯ เพราะฉันคิดว่าพวกเขาชอบ "วัตถุ" แต่หน้าเกี่ยวกับเรา "เกี่ยวกับ" ทรัพยากรประเภทไหน มันเป็นทรัพยากรในแง่ของคำว่าสงบหรือไม่? นอกจากนี้ถ้าฉันไปที่ URL "http://www.example.com/" ฉันจะขอทรัพยากรอะไร ทรัพยากรดัชนี?

11 web-development  web-applications  web  rest  http 

ฉันมีสถานการณ์ต่อไปนี้: ผู้ใช้ทำให้GETคำขอไป/projects/1และได้รับการETag ผู้ใช้ทำการร้องขอPUT/projects/1กับ ETag จากขั้นตอน # 1 ผู้ใช้ทำการร้องขอ PUT อื่น/projects/1โดยใช้ ETag จากขั้นตอนที่ # 1 โดยปกติคำขอ PUT ที่สองจะได้รับการตอบสนอง 412 เนื่องจาก ETag ตอนนี้ค้าง - คำขอ PUT แรกแก้ไขทรัพยากรดังนั้น ETag จึงไม่ตรงกันอีกต่อไป แต่จะเกิดอะไรขึ้นถ้าคำขอ PUT ทั้งสองนั้นถูกส่งในเวลาเดียวกัน คำขอ PUT แรกไม่มีเวลาในการประมวลผลและอัปเดตทรัพยากรก่อน PUT # 2 มาถึงซึ่งทำให้ PUT # 2 เขียนทับ PUT # 1 จุดรวมของการล็อคในแง่ดีคือการที่จะไม่เกิดขึ้น ...

11 rest  language-agnostic  concurrency  http 

ฉันมีหน้าเว็บที่มีรูปแบบตัวช่วยสร้าง ปุ่มส่งไปยัง API จะอยู่ในขั้นตอนที่ 4 ของตัวช่วยสร้าง อย่างไรก็ตามฉันต้องการให้ข้อมูลที่ป้อนถูกจัดเก็บในฐานข้อมูลก่อนที่จะย้ายไปยังขั้นตอนถัดไปในตัวช่วย ฉันต้องการให้ REST API ทำงานสำหรับหน้าเว็บที่มีแท็บเดียว ดังนั้นฉันจึงออกแบบ API ให้ทำแบบสอบถามพารามิเตอร์ action = draft หรือส่ง หากการดำเนินการเป็นแบบร่างเฉพาะฟิลด์ที่บังคับเท่านั้น หากมีการส่งการกระทำฟิลด์ทั้งหมดจะถูกบังคับใช้ การตรวจสอบในชั้นบริการของ REST API จะดำเนินการตามพารามิเตอร์การสืบค้น ดูเหมือนว่าฉันจะระบุ if / else ในเอกสารอย่างชัดเจน นี่เป็นรูปแบบที่ยอมรับได้ของการออกแบบ RESTful หรือไม่ อะไรคือการออกแบบที่ดีที่สุดตามข้อกำหนดเหล่านี้

11 design  rest 

ฉันมักจะเห็นสิ่งต่อไปนี้ในเอกสาร HTML <link rel="self" href="http://example.com/something"> หรือเช่นนี้ใน JSON link: { rel="self", href="http://example.com/something" } หรือใน XML <atom:link rel="self" href="http://example.com/something" /> ดังนั้นฉันมีคำถาม: ทำไมรวมลิงค์นี้ มีข้อดีอะไรบ้าง? (โปรดบอกฉันว่ามันมีเหตุผลและมันไม่ใช่แค่ "การปฏิบัติที่ดี" เครื่องราง) ฉันจะใช้ประโยชน์จากลิงก์นี้ในลูกค้าของฉันได้อย่างไร กรณีการใช้งานของลิงค์นี้มีอะไรบ้าง? เมื่อใดที่ฉันไม่ควรใช้ลิงก์นี้ เมื่อไรจึงจะไม่มีประโยชน์ที่จะรวมไว้

11 rest  web-api