Ответы с примерами связанных ресурсов - это здорово, но только половина картины.
Итак, представьте, что вы разрабатываете веб-сайт. Вы пишете историю,
Я хочу иметь возможность искать адрес по почтовому индексу, чтобы я мог выбрать адрес доставки
Затем вы создадите сайт, чтобы отвлечь пользователя в это путешествие, и попытаться связать страницы вместе в рабочем процессе.
Дизайн веб-сайта, который брал их для поиска адреса, а затем оставлял их для копирования адреса в буфер обмена и затем возврата к форме адреса доставки, был бы не очень полезным.
REST API использует шаблоны, которые мы воспринимаем как само собой разумеющееся в Интернете, для взаимодействия машина-машина.
Поиск функции почтового индекса не должен быть base/addresses/{postcode}
, и коллекция возвращается, даже если каждый адрес ссылается на полный адрес и некоторые ссылки для редактирования, потому что это тупик; потребитель API должен будет угадать, как использовать адрес.
Вместо этого мотив для функции должен быть встроен в поток, в котором она используется, так что путешествие заканчивается в начале:
1 GET /orders/123/shipping
200 OK { Current shipping details + link to parent + link to address picker }
2 -> GET /orders/123/shipping/addresspicker
200 OK { Link and form for searching for a postcode }
3 -> GET /orders/123/shipping/addresspicker?postcode=tn11tl
200 OK { List of addresses each with link to pick it }
4 -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3
200 OK { Current shipping details + link to parent + link to address picker }
Это путешествие пользователя, и в конце вы можете увидеть влияние потока на заказ.
HTTP-запрос / ответ не является строго частью REST, но я не думаю, что кто-либо когда-либо видел приложение REST, отличное от HTTP.
Теперь эти URL могут быть любым набором символов, они просто идентификаторы, я сделал их красивыми, потому что они имеют смысл для людей. Машина будет использовать rel
, чтобы понять, что они делают, не зависимо от читаемого href
.