У меня есть API для системы бронирования. Две основные объекты: - Бронирование и недвижимостиКакова наилучшая практика для URL-адресов REST при запросе зарезервирована или существует
public class Booking
{
public DateTime CheckInDate {get; set;}
public DateTime CheckOutDate {get; set;}
public int PropertyId {get; set;}
}
public class Property
{
public int Id {get; set;}
}
мне нужно знать, если определенное свойство доступно в течение периода или нет.
Действительно ли этот URL-адрес действителен для этого запроса?
/апи/Бронирование/availableProperty? PropertyID = 1 & CheckInDate = 1/1/2017 & CheckOutDate = 1/2/2017
Справедливо ли возвращать логическое значение в результате URL isPropertyReserved ?
/апи/Бронирование/isPropertyReserved? PropertyID = 1 & CheckInDate = 1/1/2017 & CheckOutDate = 1/2/2017
В целях модульности мы в настоящее время не хотим, чтобы недвижимость зависела от бронирования, но позиции переключения приемлемы; бронирование может зависеть от имущества. Возможно, нам следует пересмотреть отношения между собственностью и бронированием. – Fakhry
Конечно, я не знаю весь домен. Разумеется, при разработке _resources_ вы должны учитывать свои бизнес-правила. Мое намерение состояло в том, чтобы показать, что вместо _procedural_ call 'isPropertyReserved' вы можете создать ресурс, отвечающий на тот же вопрос в стиле отдыха. Например. 'api \ bookings \ 1' может вернуть даты бронирования для Property 1.' api \ bookings \ 2017-02-03 \ 2017-03-03' может вернуть все Свойства, доступные для бронирования в этом диапазоне дат. Окончательно, 'api \ bookings \ 2017-02-03 \ 2017-03-03 \ 1' может вернуть статус бронирования (например,« забронировано »или« доступно »). –
Хорошая практика - вернуть свойства, хотя URL-адрес api относится к бронированию «api \ bookings \ 2017-02-03 \ 2017-03-03» ?. Я думаю, что это может привести к путанице. – Fakhry