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

การตั้งค่า: ฉันมีสองรุ่นคือรถยนต์และโรงรถซึ่งรถยนต์สามารถอยู่ในโรงรถได้ ดังนั้น URL ของฉันดูเหมือน:

/car/xxxx
  xxx == car id
  returns car with given id

/garage/yyy
  yyy = garage id
  returns garage with given id

รถยนต์สามารถมีอยู่ได้ด้วยตัวเอง (ดังนั้น / รถยนต์) หรือสามารถอยู่ในโรงรถได้ เป็นวิธีที่ถูกต้องในการเป็นตัวแทนพูดรถยนต์ทุกคันในโรงรถที่ให้ไว้คืออะไร? สิ่งที่ต้องการ:

/garage/yyy/cars     ?

วิธีการเกี่ยวกับการรวมกันของรถยนต์ในโรงรถ yyy และ zzz?

วิธีที่ถูกต้องในการแสดงการค้นหารถยนต์ที่มีคุณลักษณะบางอย่างคืออะไร พูดว่า: ให้ฉันดูซีดานสีน้ำเงินทั้งหมดด้วย 4 ประตู:

/car/search?color=blue&type=sedan&doors=4

หรือว่าควรจะเป็น / รถยนต์แทน

ดูเหมือนว่าการใช้ "การค้นหา" ไม่เหมาะสม - เป็นวิธี / คำที่ดีกว่าอะไร ควรเป็น:

/cars/?color=blue&type=sedan&doors=4

พารามิเตอร์การค้นหาควรเป็นส่วนหนึ่งของ PATHINFO หรือ QUERYSTRING หรือไม่

ในระยะสั้นฉันกำลังมองหาคำแนะนำสำหรับการออกแบบ url ข้ามรุ่นและสำหรับการค้นหา

[อัพเดต] ฉันชอบคำตอบของจัสติน แต่เขาไม่ครอบคลุมกรณีการค้นหาหลายช่อง:

/cars/color:blue/type:sedan/doors:4

หรืออะไรทำนองนั้น เราไปจากอย่างไร

/cars/color/blue

กรณีหลายฟิลด์?

สำหรับการค้นหาให้ใช้ querystrings นี่คือการพักผ่อนที่สมบูรณ์แบบ:

/cars?color=blue&type=sedan&doors=4

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

การออกแบบ URL ที่น่ารักสงบกำลังเกี่ยวกับการแสดงทรัพยากรตามโครงสร้าง (โครงสร้างไดเรกทอรีเหมือนวันที่: บทความ / 2005/5/13, วัตถุและคุณลักษณะของมัน .. ), เครื่องหมายทับ/บ่งบอกถึงโครงสร้างลำดับชั้นใช้-idแทน

โครงสร้างลำดับชั้น

ฉันจะเป็นคนชอบ:

/garage-id/cars/car-id
/cars/car-id   #for cars not in garages

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

ค้นหา

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

/cars?color=blue;type=sedan   #most prefered by me
/cars;color-blue+doors-4+type-sedan   #looks good when using car-id
/cars?color=blue&doors=4&type=sedan   #I don't recommend using &*

หรืออะไรก็ตามที่ไม่ใช่สแลชตามที่อธิบายไว้ข้างต้น
สูตร: /cars[?;]color[=-:]blue[,;+&], * ถึงแม้ว่าฉันจะไม่ใช้&เครื่องหมายเพราะมันเป็นสิ่งที่ไม่สามารถจดจำได้จากข้อความเมื่อแรกเห็น

** คุณรู้หรือไม่ว่าการผ่านวัตถุ JSON ใน URI นั้นสงบแล้ว **

รายการตัวเลือก

/cars?color=black,blue,red;doors=3,5;type=sedan   #most prefered by me
/cars?color:black:blue:red;doors:3:5;type:sedan
/cars?color(black,blue,red);doors(3,5);type(sedan)   #does not look bad at all
/cars?color:(black,blue,red);doors:(3,5);type:sedan   #little difference

คุณสมบัติที่เป็นไปได้?

ปฏิเสธสตริงการค้นหา (!)
ในการค้นหารถยนต์ใด ๆ แต่ไม่ใช่ ดำและแดง :
?color=!black,!red
color:(!black,!red)

เข้าร่วมค้นหาการ
ค้นหารถยนต์สีแดงหรือสีน้ำเงินหรือสีดำที่มี3ประตูในโรงรถ id 1..20หรือ101..103หรือ999แต่ไม่ใช่ 5 /garage[id=1-20,101-103,999,!5]/cars[color=red,blue,black;doors=3]
จากนั้นคุณสามารถสร้างคำค้นหาที่ซับซ้อนมากขึ้น (ดูที่การจับคู่แอตทริบิวต์ CSS3สำหรับแนวคิดของการจับคู่สตริงย่อยเช่นการค้นหาผู้ใช้ที่มี "bar" user*=bar)

ข้อสรุป

อย่างไรก็ตามนี้อาจจะมีส่วนที่สำคัญที่สุดสำหรับคุณเพราะคุณสามารถทำมัน แต่คุณชอบหลังจากทั้งหมดเพียงแค่เก็บไว้ในใจที่สงบ URI แสดงให้เห็นถึงโครงสร้างซึ่งเป็นที่เข้าใจได้อย่างง่ายดายเช่นไดเรกทอรีเหมือน/directory/file, /collection/node/itemวัน/articles/{year}/{month}/{day}.. และเมื่อคุณไม่ใช้ กลุ่มสุดท้ายใด ๆ คุณจะรู้ทันทีว่าคุณได้อะไร

ดังนั้น .. , อักขระเหล่านี้ทั้งหมดไม่ได้รับอนุญาต :

• ไม่ได้จอง: a-zA-Z0-9_.-~
  โดยทั่วไปแล้วอนุญาตให้เข้ารหัสทั้งสองแบบและไม่ใช่ทั้งสองวิธีนั้นจะเทียบเท่ากัน
• ตัวอักษรพิเศษ: $-_.+!*'(),
• สงวนไว้: ;/?:@=&
  อาจไม่ได้รับการเข้ารหัสเพื่อจุดประสงค์ในการเป็นตัวแทนมิฉะนั้นจะต้องมีการเข้ารหัส

• ไม่ปลอดภัย: <>"#%{}|\^~[]`
  ทำไมไม่ปลอดภัยและทำไมจึงควรเข้ารหัส: RFC 1738 ดูที่ 2.2

  ดูที่RFC 1738 # page-20เพื่อดูคลาสอักขระเพิ่มเติม

RFC 3986 ดู 2.2
แม้จะมีสิ่งที่ฉันพูดก่อนหน้านี้นี่คือความแตกต่างทั่วไปของ delopes ซึ่งหมายความว่าบาง"มี"สำคัญกว่าคนอื่น ๆ

• delimeters ทั่วไป: :/?#[]@
• ย่อย delimeters: !$&'()*+,;=

การอ่านเพิ่มเติม:
ลำดับชั้น: ดู 2.3 , ดูที่ 1.2.3
url path พารามิเตอร์ syntax
CSS3 attribute ที่ตรงกับ
IBM: RESTful Web services - ข้อมูลพื้นฐาน
หมายเหตุ: RFC 1738 ได้รับการอัพเดตโดย RFC 3986

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

• ไม่อนุญาตให้ใช้อักขระทั้งหมดที่จำเป็นสำหรับการค้นหาใน URL เครื่องหมายวรรคตอนและอักขระ Unicode ส่วนใหญ่จะต้องเข้ารหัส URL เป็นพารามิเตอร์สตริงแบบสอบถาม ฉันกำลังต่อสู้กับปัญหาเดียวกัน ฉันต้องการใช้ XPath ใน URL แต่ไม่รองรับไวยากรณ์ XPath ทั้งหมดที่เข้ากันได้กับพา ธ URI ดังนั้นสำหรับเส้นทางแบบง่าย ๆ/cars/doors/driver/lock/combinationจะเหมาะสมที่จะค้นหาcombinationองค์ประกอบ '' ในเอกสาร XML ประตูคนขับ แต่/car/doors[id='driver' and lock/combination='1234']ไม่เป็นมิตร

• มีความแตกต่างระหว่างการกรองทรัพยากรตามหนึ่งในคุณลักษณะและระบุทรัพยากร

  ตัวอย่างเช่นตั้งแต่

  /cars/colors ส่งคืนรายการสีทั้งหมดสำหรับรถยนต์ทุกคัน (ทรัพยากรที่ส่งคืนคือชุดของวัตถุสี)

  /cars/colors/red,blue,green จะส่งคืนรายการวัตถุสีที่เป็นสีแดงสีน้ำเงินหรือสีเขียวไม่ใช่ชุดสะสมของรถยนต์

  ในการส่งคืนรถยนต์เส้นทางจะเป็น

  /cars?color=red,blue,green หรือ /cars/search?color=red,blue,green

• พารามิเตอร์ในเส้นทางนั้นอ่านยากกว่าเนื่องจากคู่ชื่อ / ค่าไม่แยกออกจากส่วนที่เหลือของเส้นทางซึ่งไม่ใช่คู่ชื่อ / ค่า

หนึ่งความคิดเห็นล่าสุด ฉันชอบ/garages/yyy/cars(พหูพจน์เสมอ) ถึง/garage/yyy/cars(อาจเป็นคำผิดในคำตอบเดิม) เพราะมันหลีกเลี่ยงการเปลี่ยนเส้นทางระหว่างเอกพจน์และพหูพจน์ สำหรับคำที่มีส่วนเสริมการเปลี่ยนแปลงนั้นไม่ได้เลวร้ายนัก แต่การเปลี่ยน/person/yyy/friendsไปเป็น/people/yyyเรื่องที่ยุ่งยาก

หากต้องการขยายคำตอบของปีเตอร์ - คุณสามารถค้นหาทรัพยากรชั้นหนึ่ง:

POST    /searches          # create a new search
GET     /searches          # list all searches (admin)
GET     /searches/{id}     # show the results of a previously-run search
DELETE  /searches/{id}     # delete a search (admin)

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

มีความเป็นไปได้มากมายสำหรับการใช้การค้นหาเมื่อคุณคิดว่ามันเป็นทรัพยากร

แนวคิดนี้อธิบายรายละเอียดเพิ่มเติมในRailscastนี้

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

/search/{searchQuery}

หรือ

/search/{savedSearchName}

ฉันใช้สองวิธีเพื่อทำการค้นหา

1) กรณีที่ง่ายที่สุดในการค้นหาองค์ประกอบที่เกี่ยวข้องและสำหรับการนำทาง

    /cars?q.garage.id.eq=1

ซึ่งหมายความว่าเคียวรีรถยนต์ที่มีรหัสโรงรถเท่ากับ 1

นอกจากนี้ยังเป็นไปได้ที่จะสร้างการค้นหาที่ซับซ้อนมากขึ้น:

    /cars?q.garage.street.eq=FirstStreet&q.color.ne=red&offset=300&max=100

รถยนต์ในโรงรถทั้งหมดใน FirstStreet ที่ไม่ใช่สีแดง (หน้า 3, 100 องค์ประกอบต่อหน้า)

2) ข้อความค้นหาที่ซับซ้อนถือเป็นทรัพยากรปกติที่สร้างขึ้นและสามารถกู้คืนได้

    POST /searches  => Create
    GET  /searches/1  => Recover search
    GET  /searches/1?offset=300&max=100  => pagination in search

POST เนื้อหาสำหรับการสร้างการค้นหามีดังนี้:

    {  
       "$class":"test.Car",
       "$q":{
          "$eq" : { "color" : "red" },
          "garage" : {
             "$ne" : { "street" : "FirstStreet" }
          }
       }
    }

มันขึ้นอยู่กับ Grails (เกณฑ์ DSL): http://grails.org/doc/2.4.3/ref/Domain%20Classes/createCriteria.html

นี่ไม่ใช่ REST คุณไม่สามารถกำหนด URIs สำหรับทรัพยากรภายใน API ของคุณ การนำทางทรัพยากรจะต้องเป็นแบบไฮเปอร์เท็กซ์ ไม่เป็นไรถ้าคุณต้องการ URIs ที่น่ารักและการมีเพศสัมพันธ์จำนวนมาก แต่อย่าเรียกว่า REST เพราะละเมิดข้อ จำกัด ของสถาปัตยกรรม RESTful โดยตรง

ดูบทความนี้โดยนักประดิษฐ์ของ REST

แม้ว่าฉันจะชอบคำตอบของจัสติน แต่ฉันก็รู้สึกว่ามันหมายถึงตัวกรองมากกว่าการค้นหา ถ้าฉันต้องการทราบเกี่ยวกับรถยนต์ที่มีชื่อขึ้นต้นด้วย cam

วิธีที่ฉันเห็นคุณสามารถสร้างมันขึ้นมาในแบบที่คุณจัดการกับทรัพยากรเฉพาะ:
/ cars / cam *

หรือคุณสามารถเพิ่มมันเข้าไปในตัวกรอง:
/ cars / doors / 4 / name / cam * / cols / red สีน้ำเงิน, เขียวโดย

ส่วนตัวแล้วฉันชอบสิ่งที่ตามหลัง แต่ฉันไม่เคยเป็นผู้เชี่ยวชาญเรื่อง REST (หลังจากได้ยินครั้งแรกเมื่อ 2 สัปดาห์ก่อนเท่านั้น ... )

RESTful ไม่แนะนำให้ใช้คำกริยาใน URL / cars / search ของ URL ไม่ได้พักผ่อน วิธีที่ถูกต้องในการกรอง / ค้นหา / ให้เลขหน้า API ของคุณคือผ่านพารามิเตอร์การสืบค้น อย่างไรก็ตามอาจมีบางกรณีที่คุณต้องฝ่าฝืนกฎเกณฑ์ ตัวอย่างเช่นหากคุณค้นหาข้ามหลายแหล่งข้อมูลคุณต้องใช้สิ่งที่ต้องการ / search? q = query

คุณสามารถเข้าไปที่http://saipraveenblog.wordpress.com/2014/09/29/rest-api-best-practices/เพื่อทำความเข้าใจแนวปฏิบัติที่ดีที่สุดสำหรับการออกแบบ RESTful API

นอกจากนี้ฉันอยากจะแนะนำ:

/cars/search/all{?color,model,year}
/cars/search/by-parameters{?color,model,year}
/cars/search/by-vendor{?vendor}

ที่นี่Searchถือเป็นทรัพยากรย่อยของCarsทรัพยากร

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

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

สิ่งนี้ช่วยให้คำอธิบายที่ยืดหยุ่นยิ่งขึ้นของการค้นหารวมถึงหลีกเลี่ยงการจำกัดความยาวของ URL ของเซิร์ฟเวอร์

คำแนะนำของฉันคือ:

/garages
  Returns list of garages (think JSON array here)
/garages/yyy
  Returns specific garage
/garage/yyy/cars
  Returns list of cars in garage
/garages/cars
  Returns list of all cars in all garages (may not be practical of course)
/cars
  Returns list of all cars
/cars/xxx
  Returns specific car
/cars/colors
  Returns lists of all posible colors for cars
/cars/colors/red,blue,green
  Returns list of cars of the specific colors (yes commas are allowed :) )

แก้ไข:

/cars/colors/red,blue,green/doors/2
  Returns list of all red,blue, and green cars with 2 doors.
/cars/type/hatchback,coupe/colors/red,blue,green/
  Same idea as the above but a lil more intuitive.
/cars/colors/red,blue,green/doors/two-door,four-door
  All cars that are red, blue, green and have either two or four doors.

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

นี่คือลิงค์ไปยังหน้าอธิบายความชั่วร้ายของสตริงการสืบค้นใน REST: http://web.archive.org/web/20070815111413/http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful

ฉันใช้แคชของ Google เพราะหน้าปกติไม่ทำงานสำหรับฉันที่นี่คือลิงก์นั้นด้วย: http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful