2017-02-19 21 views
0

У меня есть 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

ответ

0

В REST, вместо того, чтобы пытаться определить многочисленные discoordinated конец API - точки для каждого отдельного случая, вы должны сосредоточиться на определении collections and resources.

В модели, Property представляет собой ресурс, который имеет идентификатор и может быть забронированы от check-in до check-out даты, так что кажется естественным ввести properties коллекции (но, в зависимости от ваших требований вы можете выбрать ввести bookings коллекцию):

запрос (получить все свойства)

GET: api/properties 

Response

[ 
    { 
    "url": "api/properties/1", 
    "bookings":[ 
     { 
     "url": "api/properties/1/bookings", 
     "checkInDate": "2017-01-01", 
     "checkOutDate": "2017-02-01" 
     } 
    ] 
    }, 
    { 
    "url": "api/properties/2", 
    "bookings": [] 
    } 
] 

Запрос (получить собственность с идентификатором 1)

GET: api/properties/1 

Response

{ 
    "url": "api/properties/1", 
    "bookings":[ 
    { 
     "url": "api/properties/1/bookings", 
     "checkInDate": "2017-01-01", 
     "checkOutDate": "2017-02-01" 
    } 
    ] 
} 

Запрос (получить все заказы на недвижимость с идентификатором 1)

GET: api/properties/1/bookings 

Response

[ 
    { 
    "url": "api/properties/1/bookings", 
    "checkInDate": "2017-01-01", 
    "checkOutDate": "2017-02-01" 
    } 
] 

Запрос (проверьте, есть ли заказ на определенную дату)

GET: api/properties/1/bookings/2017-01-15 

Ответ (информация о бронировании, если найдена; пустой результат, если нет)

{ 
    "url": "api/properties/1/bookings/2017-01-15", 
    "checkInDate": "2017-01-01", 
    "checkOutDate": "2017-02-01" 
} 
+0

В целях модульности мы в настоящее время не хотим, чтобы недвижимость зависела от бронирования, но позиции переключения приемлемы; бронирование может зависеть от имущества. Возможно, нам следует пересмотреть отношения между собственностью и бронированием. – Fakhry

+0

Конечно, я не знаю весь домен. Разумеется, при разработке _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' может вернуть статус бронирования (например,« забронировано »или« доступно »). –

+0

Хорошая практика - вернуть свойства, хотя URL-адрес api относится к бронированию «api \ bookings \ 2017-02-03 \ 2017-03-03» ?. Я думаю, что это может привести к путанице. – Fakhry