Is this a good REST URI?

Is the following URI good in REST 开发者_C百科or how can it be improved?

This is the service definition: (REST and SOAP - WCF)

    [OperationContract]
    [WebGet(ResponseFormat = WebMessageFormat.Json, UriTemplate = "/Services?CostCentreNo={CostCentreNo}&Filter={Filter}")]
    List<Services> GetServices(Int32 CostCentreNo, Int32 Filter);

This would give an example URI as:

    http://paul-hp:1337/WCF.IService.svc/rest/Services?CostCentreNo=1&Filter=1

I have a lot of get methods. and a few insert methods. Is the URI acceptable. Does it need GET/ in it or something?

edit: Okay, now i undstand it more: So If I had a sub service, it would(could) be

    /CostCenters/{CostCentreNo}/Services/{ServiceID}/SubService 

and, Insert Room booking (with over 20 parameters) could be

   /CostCentres/{CostCentreNo}/Rooms/{RoomNo}/Booking?param1={param1}....&param20=‌​{param20}  

---

hmm... one of the reasons folks use REST is to avoid query strings for anything other than actual queries. In your case, a CostCentre probably deserves its own URL, as well as a separate URL for its services. Based on your example, in my opinion only the Filter should be a query string.

I would structure your URL as follows:

/CostCenters/{CostCentreNo}/Services?Filter={Filter}

Edit:

Okay, now i undstand it more: So If I had a sub service, it would(could) be

/CostCenters/{CostCentreNo}/Services/{ServiceID}/SubService  and,

Insert Room booking (with over 20 parameters) could be

/CostCentres/{CostCentreNo}/Rooms/{RoomNo}/Booking?param1={param1}....&param20=‌​{param20}

I would recommend granting individual entities that can exist on their own URLs that are closer to the parent hierarchy, if possible. Obviously I don't know your system, but my guess is that you might want to do something along the lines of:

/CostCenters/{CostCenterNo}
/Services/{ServiceID}
/Rooms/{RoomNo}

Only use hierarchies like

/CostCenters/{CostCentreNo}/Services/{ServiceID}/

when a Service cannot exist without a CostCenter. If that is the case, by all means, go with such a hierarchy. If a Service can exist without a CostCenter, go with the former hierarchy above.

One last thing. This URL from your example:

/CostCenters/{CostCentreNo}/Services/{ServiceID}/SubService 

only makes sense if a Service can have one and only one SubService. I'm betting that your example needs a SubServiceID or something similar. And following my advice above, I would definitely say that a SubService absolutely would need to be extending a Service URL, e.g.:

/Services/{ServiceID}/SubServices/{SubServiceID}

In the above case, I would expect that a SubServiceID references the same entity pool as ServiceID, and that whatever data or view is returned by this URL would include both the Service and SubService.