ระดับการอนุญาตของผู้ใช้ใน RESTful API

สมมติว่าฉันมี บริษัท ที่จัดอันดับแมวที่น่ารักที่สุดในอินเทอร์เน็ต

ฉันเสนอทรัพยากรที่/cats/ให้แมวที่น่ารักและน่ารักคนล่าสุด

ผู้ใช้สามารถได้รับแมว 3 อันดับแรกหากพวกเขาไม่ได้ชำระเงินทั้งหมดหรือลงทะเบียน แมว 10 อันดับแรกถ้าพวกเขาจ่าย 337 ดอลลาร์และเข้าสู่ระบบและแมว 100 อันดับแรกถ้าพวกเขาจ่ายเงิน 1,337 ดอลลาร์และเข้าสู่ระบบฉันมี 'ตัวระบุผู้ใช้' เมื่อทำการร้องขอ

ในระยะสั้นผู้บริโภค/cats/จะได้รับจำนวนที่แตกต่างกันของแมวอยู่บนพื้นฐานของพวกเขาใช้การจัดอันดับ ' ฉันมีตัวระบุผู้ใช้ในส่วนสิ้นเปลือง แต่ฉันไม่มีระดับตัวแทนผู้ใช้อย่างชัดเจนในส่วนสิ้นเปลือง ฉันต้องการแจ้งให้ผู้ใช้ทราบว่าพวกเขาสามารถอัพเกรดการสมัครสมาชิกเมื่อทำการร้องขอ นั่นคือฉันต้องการที่จะแยกแยะระหว่าง3 แมวตั้งแต่ผมเพียง แต่นำเสนอ 3 แมวและ3 แมวเนื่องจากว่าสิ่งที่ระดับผู้ใช้ที่ได้รับอนุญาต

อะไรคือแนวปฏิบัติที่ดีที่สุดสำหรับการ จำกัด ทรัพยากรเนื่องจากผู้บริโภคมีสิทธิพิเศษไม่เพียงพอและ จำกัด เนื่องจากเป็นสิ่งที่ผู้บริโภคมี

ลูกค้าจะรู้ได้อย่างไรว่าพวกเขาสามารถอัพเกรดการจัดอันดับของพวกเขา? นั่นคือพวกเขามีทรัพยากรที่ จำกัด เพราะพวกเขาไม่มีสิทธิ์ การปฏิบัติที่ดีที่สุดที่นี่คืออะไร?

หมายเหตุนี่คือการทำให้เข้าใจง่ายโดยรวมของกรณีจริง นอกจากนี้เพื่อชี้แจง - อ่านชื่นชม

ปรับปรุง:

นี่คือตัวเลือกที่เราพิจารณาแล้ว:

• การจัดเก็บวัตถุการอนุญาตของผู้ใช้หนึ่งครั้งบนไคลเอนต์การสอบถามมันเมื่อดำเนินการเข้าสู่ระบบหรืออัพเกรดบัญชี
• การส่งผ่านnullค่าใน JSON บ่งชี้ว่ามีอยู่จริง แต่ไม่มีการถ่ายโอนจริง ดังนั้นแมว 10 ตัวสำหรับผู้ใช้ที่มีแมว 3 ตัวอาจเป็นได้["Garfield","Sylvester","Puss in Boots",null*7]
• ผ่านคู่ของการอนุญาตให้ใช้ทรัพยากร {cats:["Whiskers","Fluffy","Socks"],authCount:3}

ฉันอยากจะทำสิ่งนี้ให้ถูกต้องในครั้งแรกที่จะส่งมอบแมวที่น่ารักที่สุดในวิธีที่ดีที่สุดเท่าที่จะเป็นไปได้และเราและเราต้องการ

ฉันจะบอกว่ามันขึ้นอยู่กับผู้ชมของคุณ

ไม่มี dev

หากผู้ชมของคุณไม่ใช่นักพัฒนาซอฟต์แวร์ฉันจะทำตามวิธีต่อไปนี้:

สมมติว่าคุณส่งคืน JSON เพื่อเป็นตัวอย่าง

GET /cats HTTP/1.1

{
    "cats": [
        "Can I haz cheeseburger",
        "If it fits, I sits",
        "It's caturday!"
    ],
    "permissions": {
        "level": "free",
        "information": "You have access to 3 cats. Upgrade to ... to get 10 cats!"
    }
}

หรือสิ่งที่คล้ายกัน

มันเป็นข้อมูลสำหรับผู้ใช้ที่จะรู้ว่าสถานะของบัญชีของเขาคืออะไรและช่วยให้คุณสามารถใส่ข้อมูลใด ๆ ที่คุณต้องการเช่นข้อความทางการตลาด จุดสำคัญที่สุดของวิธีนี้คือให้ผู้ใช้ของคุณมองเห็นบัญชีปัจจุบันได้ง่าย

dev

อย่างไรก็ตามหากผู้ชมของคุณเป็นนักพัฒนาอย่างหมดจดแล้วฉันจะพูดว่า: ไปกับวิธี HTTP ที่สอดคล้องเต็มรูปแบบ ในการจัดเก็บข้อมูลเมตาคุณใช้ส่วนหัว HTTP

นี่คือตัวอย่าง:

GET /cats HTTP/1.1

X-Account: anonymous
X-Account-Possible-Upgrades: 2
X-Account-Limit: 3

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

X-Account-Doc: http://your/doc

แต่อีกครั้งนักพัฒนาหลายคนไม่ทราบว่า HTTP ทำงานอย่างไร

ดังนั้นมันเป็นสายของคุณ

อันที่หนึ่งถูกต้องมากกว่าอีกอันหนึ่งสามารถเข้าถึงได้มากขึ้น

อื่น ๆ

สิ่งอื่น ๆ ที่เกี่ยวข้องกับคำถามของคุณ:

• อย่าลืมเกี่ยวกับ429 คำขอมากเกินไป
• อย่าลืมเกี่ยวกับหัวข้อการตอบสนอง WWW-Authenticate

ลูกค้าจะรู้ได้อย่างไรว่าพวกเขาสามารถอัพเกรดการจัดอันดับของพวกเขา?

ขึ้นอยู่กับลูกค้า โดยปกติคุณสามารถใส่ข้อมูลดังกล่าวในรูปแบบของข้อความไฮเปอร์เท็กซ์ (aka HTML) ในเนื้อหาการตอบสนองของวิธีการ REST อย่างไรก็ตามนั่นเหมาะสมถ้าใช้ REST API กับไคลเอนต์ HTML เท่านั้น

คล้ายกับ XML และ JSON

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

แทนที่จะบอกผู้ใช้ของคุณผ่านช่องทางอื่นเช่นจดหมายข่าวว่าประโยชน์ของพวกเขาคืออะไร

สิ่งนี้ทำงานได้ดีโดยเฉพาะเมื่อบุคคลที่สมัครใช้บริการไม่ใช่ผู้ที่เขียนโปรแกรมกับ API ตัวอย่างเช่น:

จอร์จ (ผู้เป็นเกย์ที่มีความภาคภูมิใจเมื่ออายุ 36 ปี) เลือกซื้อ cute-cats-4-me.com และบอกคู่สมรสอายุ 16 ปีของเขา (ที่ดีกับระบบคอมพิวเตอร์สคริปต์รวมถึง linux) เพื่อสร้าง แอปพลิเคชั่นป้ายดิจิตอลที่แสดงลูกแมวน้อยน่ารักบนผนังในอพาร์ตเมนต์

ดังนั้นคนที่สนุกกับการเขียนโปรแกรมนี้จริง ๆ แล้วไม่ใช่ผู้รับข้อมูลที่ตรงไปตรงมามากที่สุด

อีกวิธีหนึ่งในการตอบสนองต่อการเข้าสู่ระบบและวิธีการที่ผู้ใช้ข้อมูลให้รายละเอียดเต็มไปด้วยเลือดทั้งหมด

แต่เมื่อผู้ใช้ร้องขอแมวโดยทางโปรแกรมเธอควรจะรู้อยู่แล้วว่าทำไมเธอถึงได้แมวสามตัวกลับมาหรือมากกว่านั้น แต่คุณไม่ได้แก้ปัญหาการสื่อสารด้วยรหัส

มิฉะนั้นอนุญาตให้พวกเขาสอบถามเพิ่มเติมและส่งกลับการแจ้งความล้มเหลวหากสิทธิ์ของพวกเขาไม่เพียงพอ แต่นั่นไม่ใช่ซอฟต์แวร์ที่ใช้งานง่าย