REST: доступ к элементам коллекции через несколько идентификаторов

Question

У меня есть служба REST для обработки видеосерверов в сети.

Каждый видеосервер может быть идентифицирован несколькими способами: по его серийному номеру по его названию или по его номеру машины.

Для возвращения коллекции всех серверов, доступных на моей сети, вещи довольно много просто: я определил следующий маршрут:

[Route("/servers", "GET")] 

и следующий класс запроса:

public class ServerCollection : IReturn<List<ServerDto>> 
{ 
    ... 
} 

Теперь я хотел бы вернуть конкретный сервер из своей коллекции, указав либо его серийным номером, либо его машинным именем, либо номером его машины.

Для Поступая таким образом, я определил следующие маршруты:

[Route("/servers/{SerialNumber}", "GET")] 
[Route("/servers/machinenumbers/{MachineNumber}", "GET")] 
[Route("/servers/machinenames/{MachineName}", "GET")] 

и следующий класс запроса:

public class Server : IReturn<ServerDto> 
{ 
    public uint SerialNumber { get; set; } 
    public uint MachineNumber { get; set; } 
    public string MachineName { get; set; } 
} 

Таким образом, я могу получить доступ к коллекции сервера через:

GET /servers 

и получить конкретный сервер, используя:

GET /servers/3 
GET /servers/machinenumbers/42 
GET /servers/machinenames/supercalifragilisticexpialidocious 

Это правильный путь? У меня такое ощущение, что это не очень RESTful. Должен ли я рассматривать это как поиск в моей коллекции вместо использования «искусственных» ресурсов ?

Answer 1

Я бы представлял сервис одним способом, который всегда уникален (серийный номер может быть правильным).

Для запроса я бы сделал что-то вроде /servers/?name=[name] или /server/?id=[id] или просто /servers/[serial] (если вы хотите использовать серийный номер напрямую). При запросе имени или идентификатора вы должны изменить URL-адрес в запросе на servers/[serial], чтобы сохранить URL-адрес уникальным.

Answer 2

Это нормально, если вы перенаправляете (3xx) два из URI к другому, вместо того, чтобы возвращать то же представление (2xx) на всех трех. В противном случае у вас будет время синхронизировать копии в кеше. В вашем случае представляется логичным, чтобы ресурсы машинного оборудования и машинные имена перенаправлялись на ресурсы серверов/{id}.

Во всяком случае, это общий поиск с использованием параметров k = v, которые противоречат REST. Помните, что URI идентифицируют ресурсы, а запросы являются частью URI: разные запросы идентифицируют разные ресурсы. Так как множество терминов в стилевом стиле, как правило, велико (в интересах удобства), и условия могут появляться в любом порядке, это вызывает взрыв потенциальных ресурсов (если вы не планируете полагаться на кеширование для эффективность, то у вас есть много других вариантов, но это не REST).

Answer 3

Я считаю, что это путь ServiceStack. Просто сделайте поле uint нулевым, поэтому в реализации сервиса вы уверены, что искать параметры.