REST API แนวทางปฏิบัติที่ดีที่สุด: จะใส่พารามิเตอร์ได้ที่ไหน [ปิด]

REST API สามารถมีพารามิเตอร์อย่างน้อยสองวิธี:

1. เป็นส่วนหนึ่งของเส้นทาง URL (เช่น/api/resource/parametervalue )
2. เป็นอาร์กิวเมนต์ของแบบสอบถาม (เช่น/api/resource?parameter=value )

การปฏิบัติที่ดีที่สุดที่นี่คืออะไร? มีแนวทางทั่วไปเมื่อใช้ 1 และเมื่อใช้ 2 หรือไม่

ตัวอย่างโลกแห่งความจริง: Twitter ใช้พารามิเตอร์ข้อความค้นหาเพื่อระบุช่วงเวลา ( http://api.twitter.com/1/statuses/home_timeline.json?since_id=12345&max_id=54321)

มันจะถือว่าดีกว่าการออกแบบเพื่อวางพารามิเตอร์เหล่านี้ในเส้นทาง URL หรือไม่

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

พารามิเตอร์ทางเลือกมักจะใส่ในสตริงการสืบค้นได้ง่ายขึ้น

หากคุณต้องการกลับข้อผิดพลาด 404 เมื่อค่าพารามิเตอร์ไม่สอดคล้องกับทรัพยากรที่มีอยู่แล้วฉันจะไปสู่พารามิเตอร์ส่วนเส้นทาง เช่น/customer/232ที่ 232 ไม่ใช่รหัสลูกค้าที่ถูกต้อง

อย่างไรก็ตามหากคุณต้องการส่งคืนรายการว่างแล้วเมื่อไม่พบพารามิเตอร์ฉันขอแนะนำให้ใช้พารามิเตอร์สตริงแบบสอบถาม เช่น/contacts?name=dave

หากพารามิเตอร์มีผลกับทรีย่อยของพื้นที่ URI ของคุณให้ใช้เซกเมนต์พา ธ เช่นพารามิเตอร์ภาษา /en/document/foo.txt กับ/document/foo.txt?language=en

ฉันต้องการให้ตัวระบุเฉพาะอยู่ในเซ็กเมนต์เส้นทางแทนที่จะเป็นพารามิเตอร์การสืบค้น

กฎระเบียบอย่างเป็นทางการสำหรับยูริที่พบในสเปค RFC นี้ที่นี่ นอกจากนี้ยังมีข้อกำหนด RFC อื่นที่เป็นประโยชน์อย่างมากที่นี่ซึ่งกำหนดกฎสำหรับการกำหนดพารามิเตอร์ URIs

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

1. ตัวระบุตำแหน่ง - ตัวระบุทรัพยากรเช่นรหัสหรือการกระทำ / มุมมอง
2. ตัวกรอง - พารามิเตอร์ต่างๆที่ให้การค้นหาเรียงลำดับหรือ จำกัด ชุดผลลัพธ์ให้แคบลง
3. สถานะ - การระบุเซสชันเช่นคีย์ api whatevs
4. เนื้อหา - ข้อมูลอื่น ๆ ที่จะจัดเก็บ

ทีนี้ลองดูที่ต่าง ๆ ที่พารามิเตอร์เหล่านี้ไปได้

1. ขอส่วนหัวและคุกกี้
2. สตริงการสืบค้น URL ("GET" vars)
3. เส้นทาง URL
4. สตริงข้อความค้นหา / หลายส่วน ("POST" vars)

โดยทั่วไปคุณต้องการตั้งค่าสถานะเป็นส่วนหัวหรือคุกกี้ขึ้นอยู่กับประเภทของข้อมูลสถานะ ฉันคิดว่าเราทุกคนสามารถเห็นด้วยกับเรื่องนี้ ใช้ส่วนหัว http ที่กำหนดเอง (X-My-Header) หากคุณต้องการ

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

ตัวระบุตำแหน่งเช่น "id = 5" หรือ "action = refresh" หรือ "page = 2" จะเหมาะสมกว่าที่จะเป็นพา ธ URL เช่นmysite.com/article/5/page=2ที่คุณรู้ว่าแต่ละส่วนควรจะหมายถึงอะไร (พื้นฐานเช่นบทความและ 5 เห็นได้ชัดว่าได้รับข้อมูลประเภทบทความที่มี id 5) และพารามิเตอร์เพิ่มเติมถูกระบุไว้เป็นส่วนหนึ่งของ URI พวกเขาสามารถอยู่ในรูปแบบของpage=2หรือpage/2ถ้าคุณรู้ว่าหลังจากจุดหนึ่งใน URI "โฟลเดอร์" จะถูกจับคู่คีย์ - ค่า

ตัวกรองจะอยู่ในสตริงข้อความค้นหาเสมอเนื่องจากในขณะที่พวกเขาเป็นส่วนหนึ่งในการค้นหาข้อมูลที่ถูกต้องตัวกรองเหล่านั้นจะอยู่ที่นั่นเพียงเพื่อส่งคืนชุดย่อยหรือแก้ไขสิ่งที่ Locators ส่งคืนเพียงอย่างเดียว การค้นหาในmysite.com/article/?query=Obama(เซ็ตย่อย) เป็นตัวกรองและ/article/5?order=backwards(แก้ไข) ลองคิดดูสิว่ามันทำอะไรไม่ใช่แค่สิ่งที่มันถูกเรียก!

หาก "มุมมอง" กำหนดรูปแบบผลลัพธ์แสดงว่าเป็นตัวกรอง ( mysite.com/article/5?view=pdf) เพราะจะส่งกลับการแก้ไขของทรัพยากรที่พบแทนที่จะกลับบ้านในทรัพยากรที่เราต้องการ หากมันตัดสินใจแทนส่วนใดส่วนหนึ่งของบทความที่เราจะได้เห็น ( mysite.com/article/5/view=summary) มันเป็นตัวระบุตำแหน่ง

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

หวังว่านี่จะช่วยให้ผู้คนได้รับยูเรก้าสักครู่ถ้าพวกเขาหายไปไหนจะเอาของมาใส่!

มันขึ้นอยู่กับการออกแบบ ไม่มีกฎสำหรับ URIs ที่ REST ผ่าน HTTP (สิ่งสำคัญคือพวกเขาไม่ซ้ำกัน) บ่อยครั้งที่เรื่องของรสนิยมและปรีชา ...

ฉันใช้วิธีการดังต่อไปนี้:

• url path-element: ทรัพยากรและ path-element สร้างการสำรวจเส้นทางไดเรกทอรีและ subresource (เช่น / items / {id}, / users / items) เมื่อไม่แน่ใจถามเพื่อนร่วมงานของคุณหากพวกเขาคิดว่าการสำรวจเส้นทางนั้นและพวกเขาคิดว่าใน "ไดเรกทอรีอื่น" ส่วนใหญ่เส้นทางองค์ประกอบเป็นตัวเลือกที่เหมาะสม
• พารามิเตอร์ url: เมื่อไม่มีการแวะผ่านจริงๆ (ทรัพยากรการค้นหาที่มีหลายพารามิเตอร์การสืบค้นเป็นตัวอย่างที่ดีมากสำหรับสิ่งนั้น)

IMO พารามิเตอร์ควรจะดีกว่าเป็นอาร์กิวเมนต์ของแบบสอบถาม url ใช้เพื่อระบุทรัพยากรในขณะที่พารามิเตอร์เคียวรีที่เพิ่มเข้ามาเพื่อระบุว่าส่วนใดของทรัพยากรที่คุณต้องการทรัพยากรใด ๆ ที่รัฐควรมี ฯลฯ

ตามการดำเนินการ REST

1) ตัวแปรพา ธใช้สำหรับการดำเนินการโดยตรงกับทรัพยากรเช่นรายชื่อผู้ติดต่อหรือเพลง
ภายนอก GET etc / api / resource / {songid} หรือ
GET etc / api / resource / {contactid} จะส่งคืนข้อมูลที่เกี่ยวข้อง

2) Query perms / argumentใช้สำหรับทรัพยากรแบบตรงเช่น metadata ของเพลงเช่น GET / api / resource / {songid}? metadata = ประเภทมันจะส่งคืนข้อมูลประเภทสำหรับเพลงนั้น ๆ

"Pack" และโพสต์ข้อมูลของคุณกับ "บริบท" ที่ universe-resource-locator จัดเตรียมไว้ให้ซึ่งหมายถึง # 1 เพื่อประโยชน์ของ locator

คำนึงถึงข้อ จำกัด ด้วย # 2 ฉันชอบ POST ถึง # 1

หมายเหตุ: มีการพูดถึงข้อ จำกัด ต่างๆ

POST ในมีขนาดสูงสุดสำหรับเนื้อหาพารามิเตอร์ POST หรือไม่

GET in มีการจำกัดความยาวของคำขอ GET หรือไม่ และขนาดสูงสุดของพารามิเตอร์ URL ใน _GET

ps ข้อ จำกัด เหล่านี้ขึ้นอยู่กับความสามารถของไคลเอ็นต์ (เบราว์เซอร์) และเซิร์ฟเวอร์ (การกำหนดค่า)

ตามมาตรฐาน URIพา ธ ใช้สำหรับพารามิเตอร์ลำดับชั้นและเคียวรีใช้สำหรับพารามิเตอร์ที่ไม่ใช่ลำดับชั้น Ofc มันอาจเป็นอัตนัยสิ่งที่เป็นลำดับชั้นสำหรับคุณ

ในสถานการณ์ที่มีการกำหนด URI หลายแห่งให้กับทรัพยากรเดียวกันฉันต้องการใส่พารามิเตอร์ - จำเป็นสำหรับการระบุ - ลงในพา ธ และพารามิเตอร์ - ที่จำเป็นในการสร้างการแสดง - ลงในแบบสอบถาม (สำหรับฉันด้วยวิธีนี้มันง่ายกว่าเส้นทาง)

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

• /users/123 และ /users/123?fields="name, age"
• /users และ /users?name="John"&age=30

เพื่อลดแผนที่ฉันชอบที่จะใช้วิธีการต่อไปนี้:

• /users?name="John"&age=30
• /users/name:John/age:30

ดังนั้นมันขึ้นอยู่กับคุณจริงๆ (และเราเตอร์ฝั่งเซิร์ฟเวอร์ของคุณ) วิธีที่คุณสร้าง URI ของคุณ

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

ในฐานะโปรแกรมเมอร์บ่อยครั้งที่ลูกค้าสิ้นฉันชอบอาร์กิวเมนต์การสืบค้น นอกจากนี้สำหรับฉันมันแยกเส้นทาง URL จากพารามิเตอร์เพิ่มความชัดเจนและมีการขยายเพิ่มเติม นอกจากนี้ยังช่วยให้ฉันมีตรรกะแยกต่างหากระหว่างการสร้าง URL / URI และตัวสร้างพารามิเตอร์

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

ไม่มีกฎที่ยากและรวดเร็ว แต่กฎของหัวแม่มือจากจุดยืนเชิงแนวคิดล้วนๆที่ฉันชอบใช้สามารถสรุปได้สั้น ๆ เช่นนี้: เส้นทาง URI (ตามคำจำกัดความ) หมายถึงทรัพยากรและพารามิเตอร์แบบสอบถามเป็นตัวดัดแปลงในทรัพยากรนั้น . เพื่อให้ห่างไกลที่อาจไม่ได้ช่วย ... ด้วย REST API คุณมีวิธีการที่สำคัญของการปฏิบัติตามทรัพยากรที่เดียวโดยใช้GET, และPUT DELETEดังนั้นสิ่งที่ควรแสดงในเส้นทางหรือเป็นพารามิเตอร์สามารถลดลงได้ว่าวิธีการเหล่านั้นเหมาะสมสำหรับการเป็นตัวแทนในคำถาม คุณจะให้เหตุผลPUTบางอย่างในเส้นทางนั้นและมันจะเป็นความหมายทางเสียงที่จะทำเช่นนั้น? คุณสามารถแน่นอนPUTบางสิ่งบางอย่างเกี่ยวกับที่ใดก็ได้และโค้งด้านหลังเพื่อจัดการกับมัน แต่คุณควรจะเป็นPUTการใช้ทรัพยากรจำนวนเท่าใดในการเป็นตัวแทนของทรัพยากรจริงและไม่ใช่รุ่นที่ไม่จำเป็นต้องมีบริบท การPOST. หากคุณต้องการเพิ่มลงในคอลเลกชันเฉพาะสิ่งที่จะเป็น URL ที่เหมาะสมPOST

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

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

การนำมุมมองเชิงทรัพยากรประเภทนี้ไปใช้สามารถจับคู่กับกราฟวัตถุของแบบจำลองโดเมนของคุณได้อย่างง่ายดายและผลักดันตรรกะของ API ไปยังจุดที่ทุกอย่างทำงานได้อย่างหมดจดและมีวิธีการจัดทำเอกสารด้วยตนเองค่อนข้างชัดเจน แนวคิดนี้สามารถทำให้ชัดเจนยิ่งขึ้นโดยหลีกเลี่ยงระบบที่ใช้การกำหนดเส้นทาง URL แบบดั้งเดิมที่แมปไปยังโมเดลข้อมูลที่ไม่เหมาะสม (เช่น RDBMS) Apache Slingจะเป็นจุดเริ่มต้นที่ดีอย่างแน่นอน แนวคิดของการส่งผ่านวัตถุในระบบเช่นZopeยังให้สัญญาณอะนาล็อกที่ชัดเจนยิ่งขึ้น

นี่คือความคิดเห็นของฉัน

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

ตัวอย่าง:

/calendar/2014-08-08/events

ควรให้กิจกรรมในปฏิทินสำหรับวันนั้น

หากคุณต้องการกิจกรรมสำหรับหมวดหมู่ที่เฉพาะเจาะจง

/calendar/2014-08-08/events?category=appointments

หรือหากคุณต้องการกิจกรรมนานกว่า 30 นาที

/calendar/2014-08-08/events?duration=30

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

ฉันมักจะมีแนวโน้มที่ # 2 เป็นอาร์กิวเมนต์แบบสอบถาม (เช่น / api / ทรัพยากร? พารามิเตอร์ = ค่า)

ตัวเลือกที่สามคือการโพสต์พารามิเตอร์ = ค่าในร่างกายจริง

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

ไม่ว่าคุณจะเลือกคนไหนให้แน่ใจว่าคุณเลือกแค่ตัวเดียวอย่าผสมและจับคู่ สิ่งนั้นนำไปสู่ ​​API ที่สับสน

"มิติ" หนึ่งหัวข้อนี้ถูกทิ้งไว้ แต่มันสำคัญมาก: มีบางครั้งที่ "แนวปฏิบัติที่ดีที่สุด" ต้องเข้ามาเกี่ยวข้องกับรูปแบบที่เรากำลังนำไปใช้หรือเพิ่มพูนความสามารถของ REST

ตัวอย่างการปฏิบัติ:

ปัจจุบันเว็บแอปพลิเคชั่นหลายตัวใช้สถาปัตยกรรม MVC (Model, View, Controller) พวกเขาถือว่าเส้นทางมาตรฐานบางอย่างมีให้มากขึ้นดังนั้นเมื่อเว็บแอปพลิเคชันเหล่านั้นมาพร้อมกับตัวเลือก "เปิดใช้งาน SEO URL"

พูดถึงเว็บแอปพลิเคชั่นที่โด่งดังอย่างหนึ่ง: ร้านค้าอีคอมเมิร์ซของ OpenCart เมื่อผู้ดูแลระบบเปิดใช้งาน "SEO URLs" มันคาดว่า URL ดังกล่าวจะอยู่ในรูปแบบ MVC มาตรฐานค่อนข้างเช่น:

http://www.domain.tld/special-offers/list-all?limit=25

ที่ไหน

• special-offers คือตัวควบคุม MVC ที่จะประมวลผล URL (แสดงหน้าข้อเสนอพิเศษ)

• list-allเป็นการกระทำหรือชื่อฟังก์ชั่นของตัวควบคุมที่จะเรียก (*)

• limit = 25 เป็นตัวเลือกโดยระบุว่า 25 รายการจะแสดงต่อหน้า

(*) list-allเป็นชื่อฟังก์ชั่นสมมติที่ฉันใช้เพื่อความชัดเจน ในความเป็นจริง OpenCart และเฟรมเวิร์ก MVC ส่วนใหญ่จะมีindexฟังก์ชันเริ่มต้นโดยนัย (และมักจะละเว้นใน URL) ที่ได้รับการเรียกเมื่อผู้ใช้ต้องการให้มีการดำเนินการเริ่มต้น ดังนั้น URL โลกแห่งความจริงจะเป็น:

http://www.domain.tld/special-offers?limit=25

ด้วยแอปพลิเคชันมาตรฐานที่เป็นธรรมหรือโครงสร้าง frameworkd คล้ายกับด้านบนคุณมักจะได้รับเว็บเซิร์ฟเวอร์ที่ปรับให้เหมาะสมซึ่งจะเขียน URL ใหม่สำหรับมัน (URL "ไม่ใช่ SEOed" ที่แท้จริงจะเป็น: http://www.domain.tld/index.php?route=special-offers/list-all&limit=25 )

ดังนั้นคุณในฐานะนักพัฒนาต้องเผชิญกับการจัดการกับโครงสร้างพื้นฐานที่มีอยู่และปรับ "แนวทางปฏิบัติที่ดีที่สุด" ของคุณเว้นแต่ว่าคุณเป็นผู้ดูแลระบบรู้วิธีปรับแต่งการตั้งค่าการเขียน Apache / NGinx อย่างแน่นอน บน.

ดังนั้น REST API ของคุณมักจะดีกว่ามากตามมาตรฐานของแอปพลิเคชันเว็บอ้างอิงทั้งเพื่อความสอดคล้องกับมันและความง่าย / ความเร็ว (และประหยัดงบประมาณ)

หากต้องการกลับไปที่ตัวอย่างที่เป็นประโยชน์ด้านบน REST API ที่สอดคล้องกันจะเป็นสิ่งที่มี URL เช่น:

http://www.domain.tld/api/special-offers-list?from=15&limit=25

หรือ (ไม่ใช่ URL SEO)

http://www.domain.tld/index.php?route=api/special-offers-list?from=15&limit=25

ด้วยการผสมผสานของ "เส้นทางที่เกิดขึ้น" ข้อโต้แย้งและ "การก่อตัวของ" ข้อโต้แย้ง

ฉันเห็น REST API จำนวนมากที่ไม่จัดการพารามิเตอร์ได้ดี ตัวอย่างหนึ่งที่เกิดขึ้นบ่อยครั้งคือเมื่อ URI มีข้อมูลที่สามารถระบุตัวบุคคลได้

http://software.danielwatrous.com/design-principles-for-rest-apis/

ฉันคิดว่าคำถามที่ได้รับการยืนยันคือเมื่อพารามิเตอร์ไม่ควรเป็นพารามิเตอร์เลย แต่ควรย้ายไปที่HEADERหรือBODYของคำขอแทน

มันเป็นคำถามที่น่าสนใจมาก

คุณสามารถใช้ทั้งคู่ไม่มีกฎที่เข้มงวดเกี่ยวกับเรื่องนี้ แต่การใช้ตัวแปรพา ธ URI มีข้อดีบางประการ:

• แคช : บริการแคชเว็บส่วนใหญ่บนอินเทอร์เน็ตไม่แคชคำขอ GET เมื่อมีพารามิเตอร์การสืบค้น พวกเขาทำเช่นนั้นเพราะมีระบบ RPC จำนวนมากที่ใช้คำขอ GET เพื่อเปลี่ยนข้อมูลในเซิร์ฟเวอร์ (ล้มเหลว !! รับจะต้องเป็นวิธีที่ปลอดภัย)

แต่ถ้าคุณใช้ตัวแปรพา ธ บริการทั้งหมดนี้สามารถแคชคำขอ GET ของคุณได้

• ลำดับชั้น : ตัวแปรเส้นทางสามารถแสดงลำดับชั้น: / เมือง / ถนน / สถานที่

มันทำให้ผู้ใช้ข้อมูลเพิ่มเติมเกี่ยวกับโครงสร้างของข้อมูล

แต่ถ้าข้อมูลของคุณไม่มีความสัมพันธ์แบบลำดับชั้นคุณยังสามารถใช้ตัวแปร Path ได้โดยใช้เครื่องหมายจุลภาคหรือเซมิโคลอน:

/ เมือง / ลองจิจูดละติจูด

ตามกฎแล้วให้ใช้เครื่องหมายจุลภาคเมื่อการเรียงลำดับพารามิเตอร์มีความสำคัญให้ใช้เครื่องหมายทวิภาคเมื่อการสั่งซื้อไม่สำคัญ:

/ IconGenerator / สีแดงสีฟ้าสีเขียว

นอกเหนือจากเหตุผลดังกล่าวมีบางกรณีที่เป็นเรื่องปกติที่จะใช้ตัวแปรสตริงข้อความค้นหา:

• เมื่อคุณต้องการให้เบราว์เซอร์ใส่ตัวแปรแบบฟอร์ม HTML ลงใน URI โดยอัตโนมัติ
• เมื่อคุณจัดการกับอัลกอริทึม ตัวอย่างเช่นเครื่องยนต์ของ Google ใช้สตริงการสืบค้น:

http: // www.google.co.th/search?q=rest

สรุปแล้วไม่มีเหตุผลที่ดีที่จะใช้วิธีใดวิธีหนึ่งนี้ แต่เมื่อใดก็ตามที่คุณทำได้ให้ใช้ตัวแปร URI