rest api path design questions -

im designing api , have countered issues, or more questions regarding good/best practices on designing api.

i'm returning missions available in system, , mission has relation employer.

v1/missions // returns available missions. v1/employer/1/missions // returns missions created employer. 

but lets person wants book mission finds interesting.

v1/missions/2?booking=true v1/employer/1/missions/2?booking=true 

i use first method since it's cleaner , simpler. don't have care ids either since know them response.

the second method looks better since i'd know employer , mission booking have.

either way, i'll have maintain these 2 routes now. , annoying part questions regarding stuff popping in head time when splitting routes behave same way other one.

hmm, think sth below:

get    /employers/{employerid}/missions/{missionid}    check if employer has mission booked. put    /employers/{employerid}/missions/{missionid}    add mission employer (create booking) delete /employers/{employerid}/missions/{missionid}    remove mission employer (cancel booking) 

or

get  /employers/{employerid}/missions/{missionid}/booked   check if employer has mission booked. put  /employers/{employerid}/missions/{missionid}/booked   put "true" book. put "false" cancel booking. 

if above doesn't suit use case or application has more complicated relations, may think making bookings resource:

• get booking (or check if exists)

  get  /bookings/{bookingid} 

• create booking:

  post  /bookings/   { "employerid": 1; "missionid": 2}  

• cancel booking

  delete  /bookings/{bookingid} 

designing rest api tricky , (especially @ beginning) requires change way think.

good luck!