วิธีออกแบบการค้นหา / กรอง RESTful [ปิด]

457

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้

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

ปิดให้บริการใน2 ปีที่ผ่านมา

ขณะนี้ฉันกำลังออกแบบและใช้งาน RESTful API ใน PHP อย่างไรก็ตามฉันไม่ประสบความสำเร็จในการนำการออกแบบเริ่มต้นไปใช้

GET /users # list of users
GET /user/1 # get user with id 1
POST /user # create new user
PUT /user/1 # modify user with id 1
DELETE /user/1 # delete user with id 1

จนถึงมาตรฐานสวยใช่มั้ย

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

GET /users?parameter1=value1&parameter2=value2&parameter3=value3&parameter4=value4

แต่ฉันต้องการที่จะมีสิ่งที่ชอบ:

GET /users
# Request body:
{
    "parameter1": "value1",
    "parameter2": "value2",
    "parameter3": "value3",
    "parameter4": "value4"
}

ซึ่งสามารถอ่านได้มากขึ้นและช่วยให้คุณตั้งค่าตัวกรองที่ซับซ้อนได้

อย่างไรก็ตามfile_get_contents('php://input')ไม่ได้ส่งคำขอคืนGETคำขอ ฉันลองhttp_get_request_body()แล้ว แต่โฮสติ้งที่ใช้ร่วมกันที่ฉันใช้ไม่มีpecl_httpอยู่ ไม่แน่ใจว่ามันจะช่วยได้หรือไม่

ฉันพบคำถามนี้และตระหนักว่า GET อาจไม่ได้มีเนื้อหาที่ร้องขอ มันค่อนข้างจะไม่สามารถสรุปได้ แต่พวกเขาแนะนำกับมัน

ดังนั้นตอนนี้ฉันไม่แน่ใจว่าจะทำอย่างไร คุณออกแบบฟังก์ชั่นการค้นหา / กรอง RESTful ได้อย่างไร

ฉันคิดว่าฉันสามารถใช้งานPOSTได้ แต่นั่นก็ดูไม่สงบมากนัก

— Erik B
แหล่งที่มา

7

ซ้ำเป็นไปได้ของการออกแบบสงบ URL สำหรับการค้นหา

— outis

60

ระวัง!!! วิธีการ GET จะต้องเป็น IDEMPOTENT และต้องเป็น "แคชได้" หากคุณส่งข้อมูลในร่างกายระบบจะแคชคำขอของคุณได้อย่างไร? HTTP อนุญาตให้แคชคำขอ GET โดยใช้ URL เท่านั้นไม่ใช่เนื้อหาคำขอ ตัวอย่างเช่นคำขอทั้งสองนี้: example.com {test: "some"} example.com {anotherTest: "some2"} ได้รับการพิจารณาเหมือนกันโดยระบบแคช: ทั้งคู่มี URL เดียวกันทั้งหมด

— jfcorugedo

15

เพียงเพิ่มคุณควรโพสต์ไปที่ / ผู้ใช้ (คอลเลกชัน) และไม่ / ผู้ใช้ (ผู้ใช้คนเดียว)

— Mladen B.

1

อีกประเด็นที่ควรพิจารณาคือเซิร์ฟเวอร์แอปส่วนใหญ่มีบันทึกการเข้าถึงที่บันทึก URL ดังนั้นอาจมีสิ่งใดเกิดขึ้นระหว่างนั้น ดังนั้นอาจมีการรั่วไหลของข้อมูลที่ไม่ได้ตั้งใจใน GET

— user3206144

2

ซ้ำซ้อนที่เป็นไปได้ของการออกแบบ URL สงบสำหรับการค้นหา

— ivan_pozdeev

396

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

ตัวอย่างเช่น:

Accept: application/json
Content-Type: application/json
POST http://example.com/people/searches
{
  "terms": {
    "ssn": "123456789"
  },
  "order": { ... },
  ...
}

คุณกำลังสร้างการค้นหาจากมุมมองของผู้ใช้ รายละเอียดการดำเนินการนี้ไม่เกี่ยวข้อง RESTful API บางตัวอาจไม่ต้องใช้ความพยายาม นั่นคือรายละเอียดการใช้งาน

— Jason Harrelson
แหล่งที่มา

209

ข้อ จำกัด หนึ่งที่สำคัญในการใช้คำขอ POST สำหรับจุดสิ้นสุดการค้นหาคือไม่สามารถคั่นหน้าได้ การทำบุ๊คมาร์คผลการค้นหา (โดยเฉพาะข้อความค้นหาที่ซับซ้อน) อาจมีประโยชน์มาก

— couchand

73

การใช้ POST เพื่อทำการค้นหาอาจทำลายข้อ จำกัด แคช REST whatisrest.com/rest_constraints/cache_excerps

— Filipe

56

การค้นหาตามธรรมชาติของพวกเขาเป็นข้อมูลชั่วคราว: ข้อมูลวิวัฒนาการระหว่างการค้นหาสองครั้งด้วยพารามิเตอร์เดียวกันดังนั้นฉันคิดว่าคำขอ GET ไม่ได้แมปอย่างหมดจดกับรูปแบบการค้นหา คำขอการค้นหาควรเป็น POST (/ Resource / search) ดังนั้นคุณสามารถบันทึกการค้นหาและเปลี่ยนเส้นทางไปยังผลการค้นหาเช่น / Resource / search / iyn3zrt ด้วยวิธีนี้ GET ขอให้ประสบความสำเร็จและสมเหตุสมผล

— sleblanc

32

ฉันไม่คิดว่าโพสต์เป็นวิธีที่เหมาะสมสำหรับการค้นหาข้อมูลสำหรับคำขอ GET ปกติอาจแตกต่างกันไปตามกาลเวลา

— สงสัย

82

นี่เป็นคำตอบที่แย่ที่สุด ฉันไม่อยากจะเชื่อเลยว่ามี upvotes มากมาย คำตอบนี้อธิบายว่าทำไม: programmers.stackexchange.com/questions/233164/…

— richard

141

หากคุณใช้เนื้อหาคำขอในคำขอ GET คุณกำลังทำลายหลักการ REST เนื่องจากคำขอ GET ของคุณจะไม่สามารถแคชได้เนื่องจากระบบแคชใช้ URL เท่านั้น

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

ใช้พารามิเตอร์ URL หรือแบบสอบถามแทนพารามิเตอร์คำขอร่างกาย

เช่น:

/myapp?var1=xxxx&var2=xxxx
/myapp;var1=xxxx/resource;var2=xxxx

ในความเป็นจริง HTTP RFC 7231 บอกว่า:

เพย์โหลดภายในข้อความขอ GET ไม่มีความหมายที่กำหนดไว้ การส่งส่วนของข้อมูลที่โหลดบนคำขอ GET อาจทำให้การใช้งานที่มีอยู่บางส่วนปฏิเสธคำขอ

สำหรับข้อมูลเพิ่มเติมลองดูที่นี่

— jfcorugedo
แหล่งที่มา

29

เรียนรู้จากความผิดพลาดของฉัน - ฉันออกแบบ API โดยใช้คำแนะนำของคำตอบที่ยอมรับ (POSTing json) แต่ย้ายไปยังพารามิเตอร์ url ความสามารถในการคั่นหน้าอาจมีความสำคัญมากกว่าที่คุณคิด ในกรณีของฉันมีความจำเป็นที่จะต้องนำทราฟฟิกไปยังคำค้นหาบางคำ (แคมเปญโฆษณา) นอกจากนี้การใช้ API ประวัติจะทำให้เข้าใจได้ง่ายขึ้นเกี่ยวกับพารามิเตอร์ URL

— Jake

2

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

— Daniel Lorenz

@DanielLorenz เพื่อประสบการณ์การใช้งานที่ดีที่สุด URL ควรยังคงมีการเปลี่ยนแปลงผ่านทาง History API ในกรณีนั้น ฉันไม่สามารถยืนได้เมื่อเว็บไซต์ไม่อนุญาตให้ใช้ฟังก์ชันการทำงานย้อนกลับของเบราว์เซอร์เพื่อนำทางไปยังหน้าก่อนหน้า และถ้ามันเป็นหน้ามาตรฐานฝั่งเซิร์ฟเวอร์ที่สร้างขึ้นวิธีเดียวที่จะทำให้มันเป็น bookmarkable คือการใช้คำขอ GET ดูเหมือนว่าพารามิเตอร์ข้อความค้นหาที่ดีเป็นวิธีที่ดีที่สุด

— นาธา

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

— Daniel Lorenz

@DanielLorenz อ่าเข้าใจแล้ว ฉันคิดว่าฉันเข้าใจผิดในสิ่งที่คุณพูด

— นาธา

70

ดูเหมือนว่าการกรอง / การค้นหาทรัพยากรสามารถนำไปใช้ในทางที่สงบ ความคิดที่จะแนะนำปลายทางใหม่ที่เรียกว่าหรือ/filters//api/filters/

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

หลังจากสร้างตัวกรองดังกล่าวแล้วมีความเป็นไปได้สองอย่างที่จะได้ผลลัพธ์การค้นหา / ตัวกรอง

ทรัพยากรใหม่ที่มี ID เฉพาะจะถูกส่งคืนพร้อมกับ201 Createdรหัสสถานะ จากนั้นใช้ ID นี้GETคำขอสามารถทำได้/api/users/:
```
GET /api/users/?filterId=1234-abcd
```
หลังจากที่ตัวกรองใหม่จะถูกสร้างขึ้นผ่านPOSTก็จะไม่ตอบกลับด้วย201 Createdแต่ในครั้งเดียวด้วย303 SeeOtherพร้อมกับส่วนหัวชี้ไปที่Location /api/users/?filterId=1234-abcdการเปลี่ยนเส้นทางนี้จะถูกจัดการโดยอัตโนมัติผ่านห้องสมุดต้นแบบ

ในทั้งสองสถานการณ์จำเป็นต้องทำการร้องขอสองครั้งเพื่อให้ได้ผลลัพธ์ที่ถูกกรองซึ่งอาจถือเป็นข้อเสียเปรียบโดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันมือถือ สำหรับการใช้งานโทรศัพท์มือถือฉันต้องการใช้เพียงครั้งเดียวเรียกร้องให้POST/api/users/filter/

จะสร้างตัวกรองได้อย่างไร

พวกเขาสามารถเก็บไว้ในฐานข้อมูลและใช้ในภายหลัง พวกเขายังสามารถเก็บไว้ในที่เก็บชั่วคราวเช่น redis และมีบาง TTL หลังจากที่พวกเขาจะหมดอายุและจะถูกลบออก

ข้อดีของความคิดนี้คืออะไร

ตัวกรองผลการกรองถูกแคชและสามารถบุ๊กมาร์กได้

— โอปอล
แหล่งที่มา

2

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

— dantebarba

2

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

— Rvy Pandey

17

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

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

— Daff
แหล่งที่มา

6

ElasticSearch ยังทำงานด้วยร่างกายและทำงานได้ดี!

— Tarun Sapra

ใช่ แต่พวกเขาควบคุมการใช้งานเซิร์ฟเวอร์อาจไม่เป็น interebs

— user432024

7

ขณะที่ฉันใช้แบ็กเอนด์laravel / phpฉันมักจะไปกับสิ่งนี้:

/resource?filters[status_id]=1&filters[city]=Sydney&page=2&include=relatedResource

PHP เปลี่ยน[]พารามิเตอร์ให้เป็นอาร์เรย์โดยอัตโนมัติดังนั้นในตัวอย่างนี้ฉันจะจบลงด้วย$filterตัวแปรที่เก็บอาร์เรย์ / วัตถุของตัวกรองพร้อมกับหน้าและแหล่งข้อมูลที่เกี่ยวข้องที่ฉันต้องการโหลด

หากคุณใช้ภาษาอื่นสิ่งนี้อาจเป็นแผนการที่ดีและคุณสามารถสร้างโปรแกรมแยกวิเคราะห์เพื่อแปลง[]เป็นอาร์เรย์ได้

— the-A-รถไฟ
แหล่งที่มา

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

— Sky

2

@Sky นี้อาจจะหลีกเลี่ยงได้โดย URI เข้ารหัสและ[ ]การใช้การแทนค่าที่เข้ารหัสของอักขระเหล่านี้เพื่อจัดกลุ่มพารามิเตอร์คิวรีเป็นวิธีปฏิบัติที่รู้จัก โดยจะใช้แม้ในJSON: สเป

— jelhan

6

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

คุณสามารถกำหนด URIs ซึ่งพารามิเตอร์ถูกเข้ารหัสตามตำแหน่งและระเบียบใน URIs เองนำหน้าด้วยเส้นทางที่คุณรู้ว่าคุณจะจับคู่กับบางสิ่ง ฉันไม่รู้ PHP แต่ฉันจะสมมติว่ามีสถานที่ดังกล่าวอยู่ (เนื่องจากมีในภาษาอื่นที่มีกรอบเว็บ):

.ie ทำการค้นหาแบบ "user" ด้วย param [i] = value [i] สำหรับ i = 1..4 ใน store # 1 (ด้วย value1, value2, value3, ... เป็นแบบย่อสำหรับพารามิเตอร์เคียวรี URI):

1) GET /store1/search/user/value1,value2,value3,value4

หรือ

2) GET /store1/search/user,value1,value2,value3,value4

หรือดังต่อไปนี้ (แม้ว่าฉันจะไม่แนะนำให้ใช้เพิ่มเติมในภายหลัง)

3) GET /search/store1,user,value1,value2,value3,value4

ด้วยตัวเลือกที่ 1 คุณ map URI ของทุกหน้าด้วย/store1/search/userการจัดการการค้นหา (หรือแล้วแต่การแต่งตั้ง PHP) ผิดนัดจะค้นหาทรัพยากรภายใต้ store1 /search?location=store1&type=user(เทียบเท่า

โดยการประชุมที่ทำเป็นเอกสารและบังคับใช้โดย API ค่าพารามิเตอร์ 1 ถึง 4 จะถูกคั่นด้วยเครื่องหมายจุลภาคและแสดงตามลำดับนั้น

ตัวเลือก 2 เพิ่มประเภทการค้นหา (ในกรณีนี้user) เป็นพารามิเตอร์ตำแหน่ง # 1 ตัวเลือกทั้งสองเป็นเพียงตัวเลือกเสริมความงาม

ตัวเลือกที่ 3 ก็เป็นไปได้เช่นกัน แต่ฉันไม่คิดว่าฉันจะชอบมัน ฉันคิดว่าความสามารถในการค้นหาภายในทรัพยากรบางอย่างควรนำเสนอใน URI ตัวเองก่อนการค้นหาตัวเอง (เช่นถ้าระบุไว้อย่างชัดเจนใน URI ว่าการค้นหานั้นเฉพาะเจาะจงภายในทรัพยากร)

ข้อได้เปรียบของการส่งผ่านพารามิเตอร์ใน URI นี้คือการค้นหาเป็นส่วนหนึ่งของ URI (เช่นทำการค้นหาในฐานะทรัพยากรทรัพยากรที่เนื้อหาสามารถ - และจะเปลี่ยนแปลงตลอดเวลา) ข้อเสียคือลำดับพารามิเตอร์บังคับ .

เมื่อคุณทำสิ่งนี้คุณสามารถใช้ GET และมันจะเป็นทรัพยากรแบบอ่านอย่างเดียว (เนื่องจากคุณไม่สามารถ POST หรือ PUT ได้ - มันจะได้รับการปรับปรุงเมื่อมันได้รับ) มันจะเป็นทรัพยากรที่มีอยู่เมื่อถูกเรียกใช้เท่านั้น

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

คุณจะทำอย่างไรกับการตัดสินใจออกแบบ แต่นี่คือวิธีที่ฉันจะทำ มันไม่สมบูรณ์แบบและฉันแน่ใจว่าจะมีกรณีที่การทำเช่นนี้ไม่ใช่สิ่งที่ดีที่สุดที่จะทำ (โดยเฉพาะอย่างยิ่งสำหรับเกณฑ์การค้นหาที่ซับซ้อนมาก)

— luis.espinal
แหล่งที่มา

7

โย่ถ้าคุณ (ใครบางคนใคร / อะไรก็ตาม) สิ่งที่เห็นด้วยกับการลงคะแนนคำตอบของฉันมันจะทำร้ายคุณอย่างน้อยก็ใส่ความคิดเห็นที่แสดงว่าคุณไม่เห็นด้วยกับสิ่งที่? ฉันรู้ว่ามันคือ interweebz แต่ ... ;)

— luis.espinal

107

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

— gardarh

14

API คือระบบทำงานบน API ก่อนไม่ใช่การประปาส่วนหลังการใช้งานครั้งแรกอาจเป็นเพียงการล้อเลียน HTTP มีกลไกสำหรับการส่งพารามิเตอร์คุณแนะนำให้ทำการสร้างใหม่ แต่จะแย่กว่านั้น (พารามิเตอร์ที่สั่งซื้อแทนที่จะเป็นคู่ของชื่อค่า) ดังนั้นการลงคะแนน

— Steven Herod

14

@gardarh - ใช่มันรู้สึกผิด แต่บางครั้งมันก็ใช้งานได้จริง วัตถุประสงค์หลักคือการออกแบบ API ที่ใช้งานได้กับบริบททางธุรกิจในมือ หากวิธีการ RESTFULL นั้นเหมาะสมกับธุรกิจของคุณ ถ้าไม่ใช่ก็อย่าไปหามัน นั่นคือออกแบบ API ที่ตรงกับความต้องการทางธุรกิจเฉพาะของคุณ การพยายามทำให้ RESTfull เป็นไปตามข้อกำหนดหลักไม่ต่างจากการถามว่า "ฉันจะใช้รูปแบบอะแดปเตอร์ในปัญหา X / Y ได้อย่างไร" อย่าวางกระบวนทัศน์ของรองเท้านอกเสียจากว่าพวกเขาจะแก้ไขปัญหาที่มีค่าจริง

— luis.espinal

1

ฉันดูทรัพยากรเป็นคอลเล็กชั่นของรัฐและพารามิเตอร์เป็นวิธีการจัดการการเป็นตัวแทนของสถานะนั้น ลองใช้วิธีนี้ถ้าคุณสามารถใช้ปุ่มและสวิตช์เพื่อปรับวิธีแสดงทรัพยากร (แสดง / ซ่อนบิตบางอย่างของมันสั่งให้แตกต่างกัน ฯลฯ ... ) การควบคุมเหล่านั้นเป็นพารามิเตอร์ หากเป็นจริงแล้วเป็นแหล่งข้อมูลที่แตกต่าง (ตัวอย่างเช่น '/ อัลบั้ม' vs '/ artist') นั่นคือเวลาที่ควรแสดงในเส้นทาง นั่นคือสิ่งที่ฉันเข้าใจได้ง่าย

— Eric Elliott

2

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

GET api/users?filter=param1%3Dvalue1%26param2%3Dvalue2

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

— พระสาทิสลักษณ์
แหล่งที่มา