Неустойчивый дизайн нарушает принцип командного запроса?

Question

Нарушает ли RESTful дизайн command and query segregation principle?

В нашем дизайне у нас есть контроллеры, которые направляют запросы на классы обслуживания.

методы в классах обслуживания, являются ли они GET/POST/PUT, всегда будет иметь возвращаемое значение:

public Dog PutDogToSleep(/*params*/) 
{ 
    dogService.Sleep(..); 
    return dog; 
} 

Я не могу найти его прямо сейчас, но я читал, что HTTP RESTful request (get/post/put) должен вернуть объект, на котором выполняется запрос. Например, если вы выполняете PUT, тогда вы будете выполнять этот put и затем возвращать текущее состояние объекта.

Поскольку наши методы что-то делают (.Sleep) И возвращают данные, они нарушают принцип команды и запроса seg?

Реализация REST не соответствует команде/запросу?

If вы делаете REST через HTTP затем RFC7231 точно описывает , какое поведение ожидается от GET, PUT, POST и DELETE.

Answer 1

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

Этот идентификатор вы можете затем вернуть потребителю вашего REST API; что в основном означает, что потребитель должен идентифицировать созданный или измененный объект; и то, что говорят specs:

«Если ресурс был создан на исходном сервере, ответ ДОЛЖЕН быть 201 (создан) и содержать объект, который описывает статус запроса и ссылается на новый ресурс, и заголовок местоположения (см. раздел 14.30). "

Кроме того, вы можете использовать проекции на:

• конструкции только для просмотра DTO, основанные на ваши объектах данных для вашей стороны запроса
команды DTO
• конструкта для вашей команды стороны

... и выставляйте тех, у кого есть служба REST, таким образом вы действительно контролируете себя тем, что вы подвергаете.