Это хороший REST URI?

Question

Является ли следующий URI хорошим в REST или как его можно улучшить?

Это определение сервиса: (REST и SOAP - WCF)

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

Это даст примерURI как:

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

У меня много методов get.и несколько методов вставки.Является ли URI приемлемым?Нужно ли в нем GET/ или что-то в этом роде?

edit: Хорошо, теперь я понимаю это подробнее: так что если бы у меня был вспомогательный сервис, он был бы (мог) быть

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

и, бронирование номера Insert (с более чем 20 параметрами) может быть

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

Answer 1

хмм ... одна из причин, по которой люди используют REST, состоит в том, чтобы избегать строк запроса для чего-либо другого , чем фактические запросы. В вашем случае CostCentre, вероятно, заслуживает свой собственный URL, а также отдельный URL для своих услуг. Исходя из вашего примера, по моему мнению, только фильтр должен быть строкой запроса.

Я бы структурировал ваш URL следующим образом:

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

Edit:

Хорошо, теперь я понимаю это больше: так, если бы у меня была вспомогательная служба, это будет (может) быть

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

Вставка Бронирование номера (более 20 параметров) может быть

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

Я бы порекомендовал предоставлять отдельным сущностям, которые могут существовать, по их собственным URL-адресам, которые ближе к родительской иерархии, если это возможно. Очевидно, я не знаю вашу систему, но я предполагаю, что вы можете захотеть сделать что-то вроде:

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

Используйте только иерархии, такие как

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

когда Сервис не может существовать без CostCenter. Если это так, во что бы то ни стало, пойти с такой иерархией. Если Сервис может существовать без CostCenter, используйте прежнюю иерархию, приведенную выше.

И последнее. Этот URL из вашего примера:

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

имеет смысл только в том случае, если у службы может быть один и только один вспомогательный сервис. Держу пари, что вашему примеру нужен SubServiceID или что-то подобное. И, следуя моему совету выше, я бы определенно сказал, что SubService, безусловно, необходимо будет расширить URL-адрес службы, например ::1010

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

В вышеприведенном случае я ожидаю, что SubServiceID ссылается на тот же пул сущностей, что и ServiceID, и что любые данные или представление, возвращаемые этим URL, будут включать как Service, так и SubService.