วิศวกรรมซอฟต์แวร์ rest

2

วิธีที่ดีที่สุดในการปรับใช้การรับรองความถูกต้องสำหรับ REST API

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

21 mobile rest login

7

เว็บแอปพลิเคชันเป็นไคลเอนต์ REST API: วิธีจัดการตัวระบุทรัพยากร

แนวคิดหลายอย่างที่เกี่ยวข้องกับความขัดแย้ง REST ในหัวของฉันเมื่อฉันลองใช้มัน ฉันมี REST-ful back-end API ระบบที่เก็บตรรกะทางธุรกิจและเว็บแอปพลิเคชันที่มี UI จากแหล่งข้อมูลต่างๆเกี่ยวกับ REST (โดยเฉพาะอย่างยิ่งส่วนที่เหลือในการปฏิบัติ: Hypermedia และระบบสถาปัตยกรรม ) ฉันรู้ว่าฉันไม่ควรเปิดเผยตัวระบุดิบของหน่วยงานของฉัน rel="self"แต่กลับเชื่อมโยงหลายมิติด้วย พิจารณาตัวอย่าง REST api มีทรัพยากรที่ส่งคืนบุคคล: <Person> <Links> <Link rel="self" href="http://my.rest.api/api/person/1234"/> </Links> <Pets> <Link rel="pet" href="http://my.rest.api/api/pet/678"/> </Pets> </Person> ปัญหาเกิดขึ้นกับเว็บแอปพลิเคชัน สมมติว่ามันส่งคืนหน้าเว็บที่มีไฮเปอร์ลิงก์ไปยังเบราว์เซอร์: <body class="person"> <p> <a href="http://my.web.app/pet/???????" /> </p> </body> ฉันควรใส่hrefคุณลักษณะอะไร ฉันจะเก็บ URL เอนทิตี API ไว้ในเว็บแอปพลิเคชันเพื่อให้สามารถรับเอนทิตีได้เมื่อผู้ใช้เปิดหน้าเป้าหมายได้อย่างไร ข้อกำหนดดูเหมือนขัดแย้งกัน: …

21 web-applications rest

4

REST กับ RESTful และบริการเว็บ“ ปกติ” - เหมือนกันหรือไม่?

ฉันได้อ่านคำจำกัดความและการอภิปรายเกี่ยวกับแอปพลิเคชัน REST และ / หรือ RESTful แล้ว แต่ฉันยังไม่เข้าใจความหมายที่แท้จริงของมัน ฉันมักจะทำงานกับแอพที่ดึงข้อมูลผ่าน GET หรือส่งข้อมูลผ่าน POST ไปยังเว็บเซอร์วิสบางตัว (โดยปกติจะเป็นสคริปต์ PHP) จากนั้นรับข้อมูลจากฐานข้อมูลหรือเขียนลงในฐานข้อมูล ตอนนี้เป็นแอปที่เงียบสงบหรือไม่ ถ้าไม่ใช่แอป RESTful จะเป็นอย่างไร อะไรคือความแตกต่างระหว่างแนวคิด RESTful และแนวคิดที่ฉันทำงานด้วย กรุณาอธิบายผ่านตัวอย่าง นอกจากนี้บางคนกำลังพูดถึง REST และบางคนเกี่ยวกับแอป RESTful ฉันพบว่าคำว่า REST หมายถึงแนวคิดเชิงทฤษฎีในขณะที่ RESTful จะใช้เมื่อเราพูดถึงแอพที่เฉพาะเจาะจง ถูกต้องหรือมีความแตกต่างระหว่างแอพ REST และ RESTful จริงหรือไม่?

21 java php web-services mobile rest

5

OAuth2 ROPC vs Basic Auth สำหรับ REST API สาธารณะหรือไม่

กรณีการใช้งานเฉพาะที่ฉันสนใจที่นี่กำลังตรวจสอบสิทธิ์ลูกค้า REST กับจุดสิ้นสุดเซิร์ฟเวอร์ที่เปิดเผยต่อสาธารณะ (เช่น REST API สาธารณะ) ทางออกที่ง่ายที่สุดที่นี่คือการตรวจสอบสิทธิ์พื้นฐาน แต่ฉันมักจะได้ยิน OAuth2 โน้มน้าวว่าเป็นวิธีแก้ปัญหาที่ยอดเยี่ยมในเกือบทุกสถานการณ์ สิ่งที่เป็นประเภทการให้สิทธิ์ OAuth2 เพียงอย่างเดียวที่เป็นไปได้สำหรับลูกค้า REST ที่รับรองความถูกต้องกับเซิร์ฟเวอร์ REST คือข้อมูลประจำตัวของรหัสผ่านเจ้าของทรัพยากร (ROPC)เนื่องจากการให้รหัสและการให้สิทธิ์โดยปริยายต้องใช้ UI / หน้าเว็บ ผู้ใช้เพื่อเข้าสู่ระบบและอนุญาตแอปไคลเอ็นต์ด้วยตนเอง วิธีการทำงานของ ROPC คือการส่งชื่อผู้ใช้ / รหัสผ่านของเจ้าของทรัพยากรและรหัสลูกค้าเป็นพารามิเตอร์สตริงแบบสอบถาม ?!? นี่คือความปลอดภัยที่น้อยลง (IMHO) จากนั้น Auth พื้นฐานซึ่งฐานอย่างน้อย 64 เข้ารหัสข้อมูลประจำตัวและส่งภายในส่วนหัวซึ่ง TLS สามารถเข้ารหัสได้! ดังนั้นผมจึงถาม: ในบริบทของ API REST ประชาชนเป็น OAuth2 ROPC จริงๆดีกว่าตรวจสอบสิทธิ์พื้นฐาน? อะไรคือความปลอดภัยมากกว่า OAuth2 ROPC ปรับปรุง …

21 rest oauth https

4

'การค้นพบ' ใน REST API ต้องการอะไรเมื่อลูกค้ายังไม่ก้าวหน้าพอที่จะใช้มันได้

การพูดคุยที่หลากหลายที่ฉันได้ดูและแบบฝึกหัดที่ฉันสแกนบน REST ดูเหมือนจะเน้นสิ่งที่เรียกว่า 'การค้นพบ' สำหรับความเข้าใจที่ จำกัด ของฉันคำศัพท์น่าจะหมายถึงว่าลูกค้าควรจะสามารถไปhttp://URL- และรับรายการสิ่งที่สามารถทำได้โดยอัตโนมัติ สิ่งที่ฉันมีปัญหาในการทำความเข้าใจ - คือ 'ลูกค้าซอฟต์แวร์' ไม่ใช่มนุษย์ พวกเขาเป็นเพียงโปรแกรมที่ไม่มีความรู้ที่เข้าใจง่ายเพื่อทำความเข้าใจว่าจะทำอย่างไรกับลิงก์ที่ให้ไว้ มีเพียงคนเท่านั้นที่สามารถไปที่เว็บไซต์และทำความเข้าใจกับข้อความและลิงก์ที่นำเสนอและดำเนินการกับมัน ดังนั้นจุดของการค้นพบคืออะไรเมื่อรหัสลูกค้าที่เข้าถึง URL ที่ค้นพบดังกล่าวไม่สามารถทำอะไรกับมันได้เว้นแต่ผู้พัฒนามนุษย์ของลูกค้าจะทำการทดลองจริง ๆ กับทรัพยากรที่นำเสนอ? ดูเหมือนว่าสิ่งเดียวกันกับการกำหนดชุดของฟังก์ชั่นที่มีอยู่ในคู่มือเอกสารเพียงจากทิศทางที่แตกต่างและจริง ๆ แล้วเกี่ยวข้องกับการทำงานมากขึ้นสำหรับนักพัฒนา เหตุใดแนวทางที่สองนี้ของการกำหนดล่วงหน้าสิ่งที่สามารถทำได้ในเอกสารภายนอกกับทรัพยากร REST ที่แท้จริงถือว่าต่ำกว่า

20 rest api hateoas

1

ทางเลือกแทน OAuth?

อุตสาหกรรมเว็บขยับ / เปลี่ยนไปใช้ OAuth เมื่อขยายบริการ API ไปยังผู้บริโภคและนักพัฒนาภายนอก มีความสง่างามในแบบง่าย ๆ .... และขั้นตอน OAuth แบบ 3 ขั้นตอนไม่ได้เลวร้ายเกินไป ... ฉันเพิ่งพบว่ามันเป็นตัวเลือกที่ดีที่สุด มีทางเลือกอื่นที่อาจดีกว่าและปลอดภัยกว่าหรือไม่ การอ้างอิงความปลอดภัยมาจาก URL ต่อไปนี้: OAuth 2.0 ไม่ดีต่อเว็บใช่ไหม OAuth 2 ที่ไม่มีลายเซ็นต์ที่ไม่ดีสำหรับเว็บ ฉันได้พบสิ่งนี้ในการแลกเปลี่ยนความปลอดภัยด้าน ITและคิดว่ามันรุนแรงจากมุมมองความปลอดภัย: OAuth / OpenID / Facebook Connect .. บ้าเหรอ? บางทีSAML 2.0เป็นทางเลือกหรือไม่ แล้วOpenIDล่ะ วัตถุประสงค์ของคำถามนี้มาจากมุมมองการเขียนโปรแกรม OAuth เป็นตัวเลือกที่ดีที่สุดที่มีอยู่ในปัจจุบันหรือไม่? มีตัวเลือกทางเลือกอื่นให้ฉันขยายเว็บแอปพลิเคชันของฉันไปยังผู้บริโภคที่ดีขึ้นจากมุมมองด้านความปลอดภัยมุมมองการนำไปใช้งานอายุการใช้งานที่ยาวนาน (ไม่ต้องทำงานซ้ำในอีกไม่กี่เดือน) ใบสมัคร

20 web-applications websites rest

5

ข้อดีข้อเสียของสถาปัตยกรรมสงบ [ปิด]

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา การสนทนาที่พบบ่อยที่สุดที่ฉันเคยเห็นเกี่ยวกับข้อดีและข้อเสียของ REST มีแนวโน้มที่จะกำหนดกรอบการสนทนาที่สัมพันธ์กับ SOAP ฉันไม่มีประสบการณ์อย่างใดอย่างหนึ่ง ขณะนี้ฉันกำลังเผชิญหน้ากับการตัดสินใจซึ่งการขาดประสบการณ์ของฉันกำลังทำให้ฉันประเมินยาก ฉันเริ่มพัฒนาแอปพลิเคชั่นที่มีองค์ประกอบหลายอย่าง - ส่วนใหญ่เป็นแง่มุมการจัดการที่อนุญาตให้เจ้าของดูแลหลายไซต์ - และส่วนต่อประสานผู้ใช้สาธารณะที่อนุญาตให้ผู้ใช้โต้ตอบกับข้อมูลที่อยู่ในโฮสต์ ฉันต้องประเมินผลกระทบของการอนุญาตให้ส่วนหลังเป็นโฮสต์ที่ใดก็ได้และสื่อสารกับอดีตผ่านสถาปัตยกรรมสงบ - หรือเรียกร้องให้ส่วนประกอบทั้งสองอยู่ในโฮสต์เดียวกัน อะไรคือนัยสำคัญของการพัฒนาสถาปัตยกรรม RESTful โดยเฉพาะอย่างยิ่งเมื่อคำนึงถึงความสามารถในด้านต่อไปนี้: 1: ความปลอดภัย 2: ประสิทธิภาพ 3: ความซับซ้อนของส่วนต่อประสาน แก้ไข: ดูที่คำตอบของคำถามนี้ - ฉันควรชี้แจง ฉันไม่ได้มองหาการเปรียบเทียบกับ SOAP - เป็นภาพรวมของแอปพลิเคชัน REST และแอปพลิเคชันที่มีส่วนประกอบทั้งหมดอยู่ในโฮสต์เดียว (ขอบคุณสำหรับคำตอบเหล่านั้นแม้ว่า!)

20 web-applications rest

4

ควรใช้รหัสสถานะ HTTP เพื่อแสดงถึงข้อผิดพลาดทางตรรกะทางธุรกิจบนเซิร์ฟเวอร์หรือไม่?

ฉันกำลังอยู่ระหว่างทางแยกที่มีการออกแบบ API บางอย่างสำหรับลูกค้า (JS ในเบราว์เซอร์) เพื่อพูดคุยกับเซิร์ฟเวอร์ เราใช้ HTTP 409 Conflict เพื่อแสดงถึงความล้มเหลวของการกระทำเนื่องจากมีการล็อคเพื่อความปลอดภัย ล็อค satefy ป้องกันไม่ให้ devs ทำการเปลี่ยนแปลงในระบบการผลิตของลูกค้าโดยไม่ได้ตั้งใจ ฉันได้รับมอบหมายให้จัดการ 409 บิตให้กับลูกค้าอย่างอ่อนโยนยิ่งขึ้นเพื่อระบุว่าเหตุใดการเรียก API เฉพาะจึงล้มเหลว โซลูชันของฉันคือการตัดตัวจัดการความล้มเหลวของการโทร AJAX ใด ๆ ของเราซึ่งจะแสดงการแจ้งเตือนลูกค้าเมื่อมีบางอย่างล้มเหลวเนื่องจาก 409 - ทั้งหมดนี้ใช้ได้และทำงานได้ดีพร้อมกับข้อผิดพลาด 4XX และ 5XX อื่น ๆ ที่ใช้กลไกเดียวกัน มีปัญหาเกิดขึ้นที่หนึ่งในตัวจัดการเส้นทางของเราตอบสนองกับ 409s เมื่อพบข้อผิดพลาดทางธุรกิจตรรกะ - AJAX wrapper ของฉันรายงานว่าล็อคความปลอดภัยอยู่ในขณะที่ลูกค้าจัดการความล้มเหลวที่มีอยู่รายงานสิ่งที่มันคิดว่ามันขึ้นอยู่กับร่างกาย ของการตอบสนอง วิธีแก้ปัญหาง่ายๆคือเปลี่ยนการตอบสนองของผู้จัดการหรือรหัสสถานะที่เราใช้เพื่อเป็นตัวแทนของล็อคความปลอดภัย ซึ่งนำฉันไปสู่ทางแยกของฉัน: ควรใช้รหัสสถานะ HTTP เพื่อแสดงถึงข้อผิดพลาดทางตรรกะทางธุรกิจหรือไม่ คำถามนี้เน้นปัญหาเดียวกันกับที่ฉันเผชิญ แต่ก็ไม่ได้รับแรงฉุดมากนัก …

20 rest api web

3

แนวคิดไม่ตรงกันระหว่าง DDD Application Services และ REST API

ฉันกำลังพยายามออกแบบแอปพลิเคชันที่มีโดเมนธุรกิจที่ซับซ้อนและข้อกำหนดเพื่อสนับสนุน REST API (ไม่ใช่ REST อย่างเคร่งครัด แต่มุ่งเน้นไปที่ทรัพยากร) ฉันมีปัญหาบางอย่างในการหาวิธีเปิดเผยโมเดลโดเมนในลักษณะที่เน้นทรัพยากร ใน DDD ลูกค้าของโมเดลโดเมนจำเป็นต้องผ่านเลเยอร์ 'Application Services' ขั้นตอนเพื่อเข้าถึงฟังก์ชันการทำงานทางธุรกิจใด ๆ ที่ใช้งานโดย Entities และ Domain Services ตัวอย่างเช่นมีแอปพลิเคชันบริการที่มีสองวิธีในการอัปเดตเอนทิตีผู้ใช้: userService.ChangeName(name); userService.ChangeEmail(email); API ของ Application Service นี้แสดงคำสั่ง (คำกริยาขั้นตอน) ไม่ใช่สถานะ แต่ถ้าเราต้องจัดหา RESTful API สำหรับแอปพลิเคชันเดียวกันนั่นก็คือโมเดลทรัพยากรของผู้ใช้ซึ่งมีลักษณะดังนี้: { name:"name", email:"email@mail.com" } API ของทรัพยากรที่มุ่งเน้น exposes รัฐไม่ได้คำสั่ง สิ่งนี้ทำให้เกิดข้อกังวลต่อไปนี้: การดำเนินการอัปเดตแต่ละครั้งกับ REST API สามารถแมปกับการเรียกขั้นตอนบริการแอปพลิเคชันอย่างน้อยหนึ่งรายการขึ้นอยู่กับคุณสมบัติที่จะถูกอัพเดตบนโมเดลรีซอร์ส การดำเนินการอัปเดตแต่ละครั้งจะดูเหมือน atomic ไปยังไคลเอนต์ …

20 architecture rest domain-driven-design

1

URL REST ที่ซ้อนกันและรหัสหลักซึ่งมีการออกแบบที่ดีกว่า

เอาล่ะเรามีสองทรัพยากร: และAlbum Songนี่คือ API: GET,POST /albums GET,POST /albums/:albumId GET,POST /albums/:albumId/songs GET,POST /albums/:albumId/songs/:songId เรารู้ว่าเราเกลียดบางเพลงมันถูกเรียกSusyเช่น เราควรsearchลงมือทำที่ไหน? คำถามอื่น โอเคตอนนี้มันเป็นของจริงมากขึ้น เราเปิดอัลบั้มที่ 1 และโหลดเพลงทั้งหมด เราสร้างวัตถุ JS removeแต่ละเก็บข้อมูลเพลงและมีวิธีการบางอย่างเพื่อให้: update, เพลงวัตถุมี ID ชื่อและสิ่งของ แต่ไม่มีเงื่อนงำเกี่ยวกับผู้ปกครองว่าเป็นของมันเพราะเราดึงรายชื่อเพลงตามการสืบค้นและมันจะไม่ดีที่จะส่งคืนรหัสผู้ปกครองด้วยกัน ฉันผิดหรือเปล่า? ดังนั้นฉันเห็นวิธีแก้ปัญหาเล็กน้อย แต่ฉันไม่แน่ใจจริงๆ ทำให้ id หลักเป็นตัวเลือก - ตามที่ได้รับพารามิเตอร์ ฉันใช้วิธีนี้ในปัจจุบัน แต่ฉันรู้สึกว่ามันน่าเกลียด List,Create /songs?album=albumId Update,Delete /songs/:songId Get /songs/?name=susy # also, solution for first question เป็นลูกผสม …

20 design design-patterns rest ajax

3

decoupling คนที่กล้าหาญ DRY เป็น REST หรือไม่?

ฉันกำลังสร้าง REST API เพื่อแสดงการทำงานส่วนใหญ่ของ Java API ที่มีอยู่ API ทั้งสองมีไว้สำหรับใช้ภายในองค์กรของฉัน ฉันไม่ต้องออกแบบเพื่อใช้ภายนอก ฉันมีอิทธิพลเหนือ API ทั้งคู่ แต่กำลังใช้งาน REST อยู่ Java API จะยังคงใช้งานต่อไปสำหรับแอปพลิเคชันในพื้นที่ (ไม่ใช่ "เลิกใช้") แต่ REST API จะใช้สำหรับการพัฒนาใหม่ที่สำคัญ บางคลาส Java API เป็นเพียงข้อมูล (beans ที่มีคุณสมบัติ, getters, setters) และอย่างน้อยสิ่งเหล่านี้ก็เหมาะสมที่จะส่งผ่าน (ในบางรูปแบบ) ผ่าน REST API เป็นข้อมูล (ซึ่งจะถูกจัดให้อยู่ในรูปแบบ XML หรือ JSON) ตัวอย่างเช่นคลาสที่เก็บข้อมูลเกี่ยวกับเครื่องเซิร์ฟเวอร์ ฉันกำลังเผชิญกับตัวเลือกต่อไปนี้สำหรับคลาสข้อมูลเหล่านี้: ฉัน ... เปิดเผยคลาส Java ดั้งเดิม …

19 java api rest coupling dry

2

การออกแบบ REST API: การโทรหลายครั้งกับการโทรครั้งเดียวไปยัง API

เรากำลังพัฒนา Rest API สำหรับเว็บไซต์อีคอมเมิร์ซซึ่งแอพมือถือจะถูกใช้งาน ในหน้าแรกของแอพเราจำเป็นต้องโทรหาแหล่งข้อมูลมากมายเช่นสไลเดอร์แบรนด์ยอดนิยมสินค้าขายดี สองตัวเลือกในการโทรด้วย API: โทรเดียว: www.example.com/api/GetAllInHome โทรหลายสาย: www.example.com/api/GetSliders www.example.com/api/GetTopBrands www.example.com/api/GetBestSellingProducts www.example.com/api/GetTrendingProducts ซึ่งเป็นวิธีที่ดีที่สุดสำหรับการออกแบบ api พักผ่อน - โทรเดียวหรือหลายอธิบายข้อดีและข้อเสีย? ซึ่งจะใช้เวลามากขึ้นในการตอบสนองต่อการร้องขอ?

19 rest api api-design url

5

RESTful API แสดงถึงการไม่มีสิ่งใด

ลองนึกภาพ API เพื่อระบุว่าบุคคลได้เลือกสัตว์วิญญาณของพวกเขาหรือไม่ พวกมันมีสัตว์วิญญาณเป็นศูนย์หรือหนึ่งตัวเท่านั้น ขณะนี้: /person/{id}/selectedSpiritAnimal เมื่อเลือกสัตว์แล้วจะคืนค่า http 200 และ {selectedAnimal:mole} แต่เมื่อไม่มีสิ่งที่เลือกก็จะส่งคืน http 404 สิ่งนี้ทำให้สัตว์วิญญาณของฉันไม่มีความสุขเนื่องจากเราแสดงถึงข้อกังวลเกี่ยวกับโดเมนที่ถูกต้องซึ่งยังไม่ได้เลือกสัตว์วิญญาณ - เป็นข้อผิดพลาด HTTP นอกจากนี้ในฐานะธุรกิจ - erm Sprit-Animal-Hampers-R-us - เราต้องการทราบเมื่อมีคนไม่มีตัวเลือกดังนั้นเราจึงสามารถแจ้งให้พวกเขาได้ การตอบสนองที่ดีกว่าคืออะไรที่นี่: HTTP 200 และ {selectedAnimal:null} หรือชัดเจนยิ่งขึ้น HTTP 200 และ {selectedAnimal:null, spiritAnimalSelected: false} หรือมันจะดีกว่าที่จะกลับ 404? เนื่องจากชอบมากthis image has not yet been uploadedเมื่อดูภาพออนไลน์จะเป็น 404 this person has not …

18 rest

3

เหตุใดจึงใช้ REST แทนกลไกคล้าย RPC ในเว็บแอปพลิเคชัน

ฉันเพิ่งเริ่มต้นเมื่อเร็ว ๆ นี้ที่ บริษัท ที่ใช้เฟรมเวิร์กแบบกำหนดเองที่ค่อนข้างแปลกสำหรับเว็บแอปพลิเคชัน แทนที่จะใช้เว็บเซอร์ RESTful จะใช้กลไก RPC เพื่อสื่อสารกับเซิร์ฟเวอร์ การสื่อสารกับเซิร์ฟเวอร์ดูเหมือนจะเป็นการเรียกใช้ฟังก์ชั่นอย่างง่าย แต่ฟังก์ชั่นนั้นจะถูกดำเนินการบนเซิร์ฟเวอร์ไม่ใช่ไคลเอนต์ บนฝั่งเซิร์ฟเวอร์มีวิธีกำหนดฟังก์ชันที่ไคลเอ็นต์สามารถเรียกได้ รายละเอียดของการแปลสิ่งนี้เป็นคำขอ http ถูกแยกออกไปอย่างสมบูรณ์ ตอนนี้ฉันเพิ่งใช้ไปแค่ช่วงสั้น ๆ แต่มันก็ค่อนข้างสะดวก แต่ฉันสงสัยว่าข้อเสียของวิธีนี้คืออะไร ดูเหมือนคนอื่น ๆ จะทำมันแตกต่างกันไปซึ่งมักเป็นสัญญาณสำหรับฉันว่าฉันอาจจะทำอะไรที่โง่หรือฉลาดด้วยอัตราต่อรองที่สูงขึ้นในอดีต

18 web-applications rest rpc

1

ตำแหน่งที่จะวางคีย์ API: ส่วนหัว HTTP ที่กำหนดเอง VS ส่วนหัวการให้สิทธิ์ด้วยชุดรูปแบบที่กำหนดเอง

ฉันกำลังออกแบบ REST API โดยใช้การอนุญาต / การพิสูจน์ตัวตนผ่านทางคีย์ API ฉันพยายามคิดออกว่าเป็นที่ที่ดีที่สุดสำหรับสิ่งนั้นและพบว่าหลายคนแนะนำให้ใช้ส่วนหัว HTTP ที่กำหนดเองเช่นProjectName-Api-Keyเช่น: ProjectName-Api-Key: abcde แต่ก็เป็นไปได้และถูกต้องตามหลักอุดมการณ์ที่จะใช้Authorizationส่วนหัวกับชุดรูปแบบที่กำหนดเองเช่น: Authorization: ApiKey abcde ในทางกลับกันฉันพบการพิจารณาว่ารูปแบบการให้สิทธิ์ที่กำหนดเองอาจไม่คาดคิดและไม่ได้รับการสนับสนุนจากลูกค้าบางรายและนำไปสู่รหัสที่กำหนดเองอยู่ดีดังนั้นจึงเป็นการดีกว่าที่จะใช้ส่วนหัวที่กำหนดเอง คุณต้องการส่งคีย์ API ไปทางไหน

17 rest api authentication authorization headers

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