เมื่อใดที่จะใช้ @QueryParam vs @PathParam

ฉันไม่ได้ถามคำถามที่ถามไว้แล้วที่นี่: อะไรคือความแตกต่างระหว่าง @PathParam และ @QueryParam

นี่คือ "แนวปฏิบัติที่ดีที่สุด" หรือคำถามการประชุม

เมื่อคุณจะใช้VS@PathParam@QueryParam

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

การใช้ PathParam สามารถสำรองไว้สำหรับหมวดหมู่ข้อมูลซึ่งจะตกอยู่ในสาขาของแผนภูมิข้อมูล PathParam สามารถใช้ในการเจาะลึกไปยังลำดับชั้นของเอนทิตี

ในขณะที่ QueryParam อาจถูกสงวนไว้สำหรับการระบุแอตทริบิวต์เพื่อค้นหาอินสแตนซ์ของคลาส

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

• /Vehicle/Car?registration=123
• /House/Colonial?region=newengland

/category?instance

@GET
@Path("/employee/{dept}")
Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ;

VS /category/instance

@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

VS ?category+instance

@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

ฉันไม่คิดว่าจะมีแบบแผนมาตรฐานในการทำเช่นนี้ มีอะไรบ้าง อย่างไรก็ตามฉันต้องการทราบว่าผู้คนใช้ PathParam กับ QueryParam อย่างไรเพื่อแยกแยะข้อมูลของพวกเขาเหมือนกับที่ฉันได้อธิบายไว้ด้านบน ฉันชอบที่จะได้ยินเหตุผลที่อยู่เบื้องหลังการฝึกฝน

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

/departments/{dept}/employees/{id}

REST API บางตัวใช้สตริงการสืบค้นสำหรับการกรองการแบ่งหน้าและการเรียงลำดับ แต่เนื่องจาก REST ไม่ใช่มาตรฐานที่เข้มงวดฉันขอแนะนำให้ตรวจสอบ REST APIs บางตัวเช่นGithubและStackoverflowและดูว่าอะไรดีสำหรับกรณีการใช้งานของคุณ

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

นี่คือสิ่งที่ฉันทำ

หากมีสถานการณ์ที่จะดึงข้อมูลเร็กคอร์ดตาม id ตัวอย่างเช่นคุณต้องรับรายละเอียดของพนักงานที่มี id เป็น 15 คุณสามารถมีทรัพยากรด้วย @PathParam

GET /employee/{id}

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

GET /employee?start=1&size=10

นี่บอกว่าการเริ่มทำงานของพนักงาน id 1 ได้รับสิบระเบียน

ในการสรุปให้ใช้ @PathParam เพื่อดึงข้อมูลตาม id User @QueryParam สำหรับตัวกรองหรือถ้าคุณมีรายการตัวเลือกคงที่ที่ผู้ใช้สามารถผ่าน

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

GET: myserver.com/myblog/posts

เพื่อรับโพสต์ด้วย id = 123 ฉันจะขอ

GET: myserver.com/myblog/posts/123

แต่เพื่อกรองรายการโพสต์ของฉันและรับโพสต์ทั้งหมดตั้งแต่วันที่ 1 มกราคม 2013 ฉันจะขอ

GET: myserver.com/myblog/posts?since=2013-01-01

ในตัวอย่างแรก "โพสต์" ระบุเอนทิตีที่เฉพาะเจาะจง (คอลเลกชันทั้งหมดของโพสต์บล็อก) ในตัวอย่างที่สอง "123" แสดงถึงเอนทิตีที่เฉพาะเจาะจง (โพสต์บล็อกเดียว) แต่ในตัวอย่างสุดท้ายพารามิเตอร์ "ตั้งแต่ = 2013-01-01" เป็นคำขอเพื่อกรองคอลเลกชันโพสต์ไม่ใช่เอนทิตีที่เฉพาะเจาะจง การแบ่งหน้าและการสั่งซื้อจะเป็นอีกตัวอย่างที่ดีเช่น

GET: myserver.com/myblog/posts?page=2&order=backward

หวังว่าจะช่วย :-)

ฉันใช้วิธีการส่วนตัวของ "ถ้ามันสมเหตุสมผลสำหรับผู้ใช้ที่คั่นหน้า URL ที่มีพารามิเตอร์เหล่านี้แล้วใช้ PathParam"

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

หากพารามิเตอร์ที่ส่งผ่านใน URL มีแนวโน้มที่จะเปลี่ยนเค้าโครง / เนื้อหาของหน้าเว็บฉันจะใช้มันเป็นแบบสอบถาม ตัวอย่างเช่นหาก URL โปรไฟล์รองรับพารามิเตอร์ที่ระบุว่าจะแสดงอีเมลผู้ใช้หรือไม่ฉันจะถือว่ามันเป็นพารามิเตอร์แบบสอบถาม (ฉันรู้ว่าคุณสามารถพูดได้ว่า&noemail=1พารามิเตอร์หรือพารามิเตอร์ใด ๆ ที่สามารถใช้เป็นพารามิเตอร์พา ธ และสร้างหน้าแยกกัน 2 หน้า - หน้าหนึ่งพร้อมอีเมลในนั้นหนึ่งหน้าไม่ได้ - แต่มีเหตุผลไม่ใช่: ยังคงเป็นหน้าเดียวกันที่มีหรือไม่มีแอตทริบิวต์บางอย่างที่แสดง

หวังว่านี่จะช่วยได้ - ฉันซาบซึ้งกับคำอธิบายที่อาจจะคลุมเครือ :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ตามที่ระบุไว้ REST ไม่ใช่มาตรฐาน แต่ถ้าคุณกำลังมองหาการใช้มาตรฐานซึ่งเป็นไปตามการประชุม URI คุณอาจพิจารณาการประชุม OData URI Ver 4 ได้รับการอนุมัติเป็นมาตรฐาน OASISและห้องสมุดที่มีอยู่สำหรับ OData สำหรับภาษาต่าง ๆ รวมทั้ง Java ผ่านApache Olingo อย่าปล่อยให้ความจริงที่ว่ามันเกิดจาก Microsoft วางคุณออกเพราะได้รับการสนับสนุนจากผู้เล่นอุตสาหกรรมอื่น ๆเช่น Red Hat, Citrix, IBM, Blackberry, Drupal, Netflix Facebook และ SAP

ผู้ใช้เพิ่มเติมอยู่ที่นี่

จากวิกิพีเดีย: ตัวค้นหาทรัพยากรที่เหมือนกัน

เส้นทางซึ่งมีข้อมูลมักจะจัดระเบียบในรูปแบบลำดับชั้นที่ปรากฏเป็นลำดับของกลุ่มที่คั่นด้วยเครื่องหมายทับ

แบบสอบถามมีตัวเลือกแยกออกจากส่วนที่ก่อนหน้านี้ด้วยเครื่องหมายคำถาม (?) ที่มีสตริงแบบสอบถามของข้อมูลที่ไม่ใช่แบบลำดับชั้น

- ตามการออกแบบแนวความคิดของ URL เราอาจใช้ PathParam สำหรับข้อมูลลำดับชั้น / ส่วนประกอบ / ที่ตั้งหรือนำ QueryParam ไปใช้เมื่อข้อมูลไม่ได้เป็นลำดับชั้น สิ่งนี้สมเหตุสมผลเนื่องจากพา ธ ได้รับการจัดเรียงตามธรรมชาติในขณะที่เคียวรีมีตัวแปรที่อาจสั่งซื้อโดยพลการ (คู่ของตัวแปร / ค่าที่ไม่เรียงลำดับ)

ผู้วิจารณ์คนก่อนหน้านี้เขียนว่า

ฉันคิดว่าหากพารามิเตอร์ระบุเอนทิตีเฉพาะคุณควรใช้ตัวแปรพา ธ

อีกเขียน

ใช้ @PathParam เพื่อดึงข้อมูลตาม id User @QueryParam สำหรับตัวกรองหรือถ้าคุณมีรายการตัวเลือกคงที่ที่ผู้ใช้สามารถผ่าน

อีก

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

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

สตริงเลขฐานสิบหกที่ยาวอาจทำให้เจือจาง / ลดคุณค่าของคำหลักในเส้นทางที่เหลือได้หรือไม่? มันอาจจะคุ้มค่าเมื่อพิจารณาถึงผลกระทบของ SEO ที่อาจเกิดขึ้นจากการวางตัวแปร / ค่าในเส้นทางหรือในแบบสอบถามและความหมายของอินเทอร์เฟซสำหรับมนุษย์ว่าเราต้องการให้ผู้ใช้สามารถสำรวจ / สำรวจลำดับชั้นของ URL โดยแก้ไขเนื้อหาของแถบที่อยู่หรือไม่ หน้า 404 ไม่พบของฉันใช้ตัวแปร SSI เพื่อเปลี่ยนเส้นทาง URL ที่เสียหายไปยังพาเรนต์โดยอัตโนมัติ! โรบ็อตการค้นหาอาจสำรวจลำดับชั้นของพา ธ ในทางตรงข้ามส่วนตัวเมื่อฉันแบ่งปัน URL บนโซเชียลมีเดียฉันจะแยกตัวระบุเฉพาะส่วนตัวออกด้วยตนเอง - โดยทั่วไปแล้วจะตัดทอนการค้นหาจาก URL โดยปล่อยเฉพาะเส้นทาง: ในกรณีนี้มียูทิลิตี้บางอย่างในการวางตัวระบุเฉพาะ ในเส้นทางมากกว่าในแบบสอบถาม ไม่ว่าเราต้องการอำนวยความสะดวกในการใช้ส่วนประกอบของเส้นทางเป็นส่วนต่อประสานกับผู้ใช้อย่างหยาบ ๆ หรือไม่นั้นขึ้นอยู่กับว่าข้อมูล / ส่วนประกอบนั้นมนุษย์สามารถอ่านได้หรือไม่ คำถามเกี่ยวกับความสามารถในการอ่านของมนุษย์เกี่ยวข้องกับคำถามเกี่ยวกับลำดับชั้น: บ่อยครั้งที่ ข้อมูลที่อาจแสดงเป็นคำหลักที่มนุษย์อ่านได้ก็มีลำดับชั้นเช่นกัน ในขณะที่ข้อมูลลำดับชั้นมักจะแสดงเป็นคำหลักที่มนุษย์อ่านได้ (เสิร์ชเอ็นจิ้นเองอาจถูกกำหนดให้เป็นการเพิ่มการใช้ URL เป็นส่วนต่อประสานกับผู้ใช้) ลำดับชั้นของคำหลักหรือคำสั่งอาจไม่ได้รับการจัดเรียงอย่างเคร่งครัด แต่โดยปกติแล้วพวกเขามักจะใกล้พอที่จะครอบคลุมกรณีอื่น ๆ ในเส้นทางป้ายทางเลือกหนึ่งเป็นกรณี "บัญญัติ"

มีคำถามหลายประเภทที่เราอาจตอบด้วย URL สำหรับแต่ละคำขอโดยพื้นฐาน:

1. เรากำลังขอ / ให้บริการบันทึก / สิ่งใด
2. เราสนใจสิ่งใด
3. เราต้องการนำเสนอข้อมูล / บันทึกอย่างไร

ไตรมาสที่ 1 คือเส้นทางที่ดีที่สุดหรือ PathParams Q3 (ซึ่งอาจถูกควบคุมผ่านชุดของพารามิเตอร์ทางเลือกและค่าเริ่มต้นโดยพลการ) ได้รับการคุ้มครองที่ดีที่สุดโดย QueryParams Q2: มันขึ้นอยู่กับ ...

คุณสามารถรองรับทั้งพารามิเตอร์เคียวรีและพารามิเตอร์พา ธ เช่นในกรณีของการรวมทรัพยากร - เมื่อการรวบรวมทรัพยากรย่อยมีเหตุผล

/departments/{id}/employees
/employees?dept=id

พารามิเตอร์เคียวรีสามารถสนับสนุนการเซ็ตย่อยแบบลำดับชั้นและไม่เป็นลำดับชั้น พารามิเตอร์พา ธ เป็นแบบลำดับชั้นเท่านั้น

ทรัพยากรสามารถแสดงหลายลำดับชั้น สนับสนุนเส้นทางสั้น ๆ ถ้าคุณจะทำการสืบค้นคอลเลกชันย่อยแบบกว้างที่ข้ามขอบเขตลำดับชั้น

/inventory?make=toyota&model=corolla
/inventory?year=2014

ใช้พารามิเตอร์การสืบค้นเพื่อรวมลำดับชั้นแบบมุมฉาก

/inventory/makes/toyota/models/corolla?year=2014
/inventory/years/2014?make=toyota&model=corolla
/inventory?make=toyota&model=corolla&year=2014

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

/words/{id}/definitions
/definitions?word=id   // not useful

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

ฉันให้ exapmle หนึ่งอันเพื่อให้เราใช้@Queryparamและเมื่อไร@pathparam

ตัวอย่างเช่นฉันใช้เวลาหนึ่ง resouce คือcarResourceชั้นเรียน

หากคุณต้องการที่จะทำให้อินพุตของวิธีการจัดการทรัพยากรของคุณแล้วใช้ประเภทพารามิเตอร์เป็น@pathaparamถ้าหากปัจจัยการผลิตของวิธีการทรัพยากรของคุณควรจะเป็นตัวเลือกแล้วเก็บประเภท@QueryParamพารามิเตอร์ที่เป็นพารามิเตอร์

@Path("/car")
class CarResource
{
    @Get
    @produces("text/plain")
    @Path("/search/{carmodel}")
    public String getCarSearch(@PathParam("carmodel")String model,@QueryParam("carcolor")String color) {
        //logic for getting cars based on carmodel and color
            -----
        return cars
    }
}

สำหรับ resouce นี้ผ่านการร้องขอ

req uri ://address:2020/carWeb/car/search/swift?carcolor=red

ถ้าคุณให้สิ่งที่ต้องการสิ่งนี้ทรัพยากรจะให้โมเดลรถและสี

 req uri://address:2020/carWeb/car/search/swift

ถ้าคุณให้สิ่งที่ต้องการสิ่งนี้วิธีการ resoce จะแสดงเฉพาะรถยนต์ที่ใช้โมเดลที่รวดเร็วเท่านั้น

req://address:2020/carWeb/car/search?carcolor=red

ถ้าคุณให้แบบนี้เราจะได้รับข้อยกเว้น ResourceNotFound เพราะในคลาส resouce รถฉันประกาศ carmodel ตาม@pathPramที่คุณต้องและควรให้ carmodel เป็น reQ uri มิฉะนั้นจะไม่ผ่าน req เพื่อ resouce แต่ถ้าคุณไม่ผ่านสี นอกจากนี้มันจะส่งผ่าน req ไปยังทรัพยากรทำไมเพราะสี@quetyParamเป็นตัวเลือกใน req

1. @QueryParam สามารถใช้งานได้อย่างสะดวกสบายกับหมายเหตุประกอบค่าเริ่มต้นเพื่อให้คุณสามารถหลีกเลี่ยงข้อยกเว้นตัวชี้โมฆะหากไม่มีการส่งผ่านพารามิเตอร์การสืบค้น

เมื่อคุณต้องการแยกพารามิเตอร์การสืบค้นจากคำขอ GET คุณสามารถกำหนดพารามิเตอร์ที่เกี่ยวข้องกับวิธีการที่จะจัดการคำขอ GET และใส่คำอธิบายประกอบด้วย@QueryParamคำอธิบายประกอบ

2. @PathParamสารสกัดจากค่า URI @Pathและการแข่งขันที่จะ และด้วยเหตุนี้จึงได้รับพารามิเตอร์อินพุต 2.1 @PathParamสามารถมากกว่าหนึ่งและตั้งค่าเป็นอาร์กิวเมนต์วิธี

   @Path("/rest")
   public class Abc {
   
       @GET
       @Path("/msg/{p0}/{p1}")
       @Produces("text/plain")
       public String add(@PathParam("p0") Integer param1, @PathParam("p1")  Integer param2 )
       {
           return String.valueOf(param1+param2);
       }
   } 

ในตัวอย่างข้างต้น
http://localhost:8080/Restr/rest/msg/{p0}/{p1},
p0การแข่งขันparam1และการแข่งขันp1 param2ดังนั้นสำหรับ URI
http://localhost:8080/Restr/rest/msg/4/6, เราได้รับผล
10

ใน REST Service JAX-RS จัดเตรียม@QueryParamและ@FormParamทั้งสองเพื่อรับข้อมูลจากการร้องขอ HTTP คุณสามารถส่งแบบฟอร์ม HTTP ได้หลายวิธีเช่น GET และ POST

@QueryParam : ยอมรับคำขอ GET และอ่านข้อมูลจากสตริงข้อความค้นหา

@FormParam: ยอมรับคำขอ POST และดึงข้อมูลจากรูปแบบ HTML หรือคำขอสื่อใด ๆ

สรุป

@Pathparam ใช้งานได้สำหรับการส่งค่าผ่านทั้งทรัพยากรและสตริงการสืบค้น

• /user/1
• /user?id=1

@Queryparam ใช้งานได้สำหรับการส่งค่าผ่าน Query String เท่านั้น

• /user?id=1