Лучшие практики запросов / ответов API .Net Core Rest

Question

Мне нужен совет о том, как лучше структурировать запросы и ответы для моего Rest API.

Я в основном пытаюсь ограничиться операциями CRUD над одним ресурсом и работаю с одним объектом: дляНапример, если ресурсом является «книга», я получаю следующие действия в контроллере:

• [HttpPost ("books")] Book Create (Book book)
• [HttpGet ("books")] Book Get (int id)

Это относительно прямолинейное движение вперед.

Теперь для более сложного примера создания ресурса мне нужно получитьсложный объект отличается от моего ресурса и возвращает объект, содержащий ресурс и дополнительные данные. Например, для ресурса Order у меня есть следующее действие в контроллере:

[HttpPost ("/ order")] CreateOrderResponse CreateOrder (CreateOrderRequest createOrderRequest)

Здесь мое действие будет использовать объект «CreateOrderRequest» для создания для создания Ордера.Затем я хотел бы вернуть объект «createOrderResponse», который содержит Order, а также дополнительную информацию, которая нужна клиенту.

Я не уверен, что это лучший способ, любой совет?

Заранее спасибо за помощь

Answer 1

Я предпочитаю следующее:

[HttpPost("/order")] CreateOrderResponse CreateOrder(CreateOrderRequest createOrderRequest)

И вот почему:

• Этим способом вы можете защитить свой общедоступный API от деталей реализации.Если вы выставите свою модель для своего API, то вы не сможете дать такую ​​же гарантию.
• Вы также можете сделать свои проверки в соответствии с форматом запроса.В некоторых случаях вам может потребоваться одно подмножество вашей модели при создании записи и другое подмножество при редактировании данных.Такой подход позволит вам справиться и с этим сценарием.
• Безопасность.Собираетесь ли вы добавить эту книгу прямо в DbContext и сохранить ее?Или прикрепите и обновите напрямую?Это могут быть потенциальные проблемы с точки зрения безопасности и качества данных.

Но есть и недостатки:

• Этот подход требует много времени.Это может не стоить потраченного времени, если вы пишете что-то в качестве учебного упражнения или быстрой реализации.И это добавляет сложности.Но тогда вы можете столкнуться со сложностью, когда поймете, что ваш объект Book недостаточен во всех случаях.
• Вы почувствуете, что в разных местах есть повторяющийся код.Код может показаться одинаковым, но варианты использования на самом деле разные и могут со временем расходиться.Наличие параметра Book будет обязательным в этот момент.