2

I have two urls:

blah.com/workorder/{dealer_code} 
blah.com/workorder/{cust_id}

Both of these return a workorder based on the data sent in. Both dealer_code and cust_id are String data (you couldn't tell the difference in them).

Supposing that there is no time or way to figure out on the back end which is which, how would you design this. I have a few ideas but don't want to lead. Also, it could get longer. What about if you had this:

blah.com/workorder/{dealer_code}/{id_no}/{category}
blah.com/workorder/{cust_id}/{ref_no}/{name}

Thoughts?

markthegrea
  • 3,731
  • 7
  • 55
  • 78
  • 1
    Is there a reason why you don't just use parameters? blah/com/workorder?d=code1&id=code2. Also, I would not duplicate the URL for things that are completely independent. – Joseph Aug 27 '12 at 20:33
  • How are query parameters not RPC? I am reading lots on REST and qp but don't understand. Don't we want an endpoint that will always return the same thing? – markthegrea Aug 27 '12 at 21:43
  • That is why I suggest that you don't use blach.com/workorder. Use blah.com/workorder/dealer?param1=A... and blah.com/workorder/customer?param1=B etc etc. They should be completely different base URLS if they are executing different code. – Joseph Aug 28 '12 at 19:45

1 Answers1

3

Go for query string parameters.

It looks like you are doing searches because you are not looking up work orders by their id (primary key), but instead searching by other fields in the work order entities.

If you are looking up a work order by it's id use:

 blah.com/workorder/{id}

Otherwise use something like:

 blah.com/workorder?dealer_code=1&cust_id=1

Similar question: RESTful URL design for search

Community
  • 1
  • 1
theon
  • 14,170
  • 5
  • 51
  • 74