Как бы вы разработали систему продажи билетов для веб-страницы?Те же шаги, которые вы применяете к веб-странице, также применимы к REST, поскольку это просто обобщение того же потока взаимодействия, который используется в Интернете.
Обычно в Интернете у вас есть ссылка, на которой вы можете увидеть событие, которое выМожно заказать билеты на.На этой странице у вас есть ссылка для заказа билетов на это конкретное шоу.В зависимости от системы, которую вы используете, вы можете увидеть расположение места проведения мероприятия в виде кнопок или изображений, по которым нужно щелкать, если существует определенный порядок мест, где доступные места отмечены зеленым, а те, которые уже зарезервированы красным или любого другого цвета.Схема, которую вы используете.Щелчок по месту активирует некоторую логику бронирования на сервере, которая возвращает почти ту же страницу, что и раньше, но на этот раз с местом, помеченным оранжевым, чтобы указать бронированиеЗатем вы нажимаете на доступное место рядом с этим местом, чтобы зарезервировать дополнительное место.Эта история продолжается до тех пор, пока у вас не будет достаточно мест, помеченных как зарезервированные, или свободных мест не будет, и у вас не останется вариантов, чтобы отменить бронирование, перейти к шагу заказа или отменить забронированные места, которые вы пометили как забронированные заранее.Как только вы будете удовлетворены своим выбором, вы найдете кнопку заказа или отправки или ссылку, где вы превращаете свое бронирование в бронирование.Это может включать некоторые дальнейшие шаги, такие как ввод вашего контактного лица и / или платежной информации.Хотя, в принципе, именно так я и спроектировал бы такую систему для Интернета.
Как вы можете видеть, это превращается в некий конечный автомат, где сервер сообщает вам все опции, которые доступны наэто текущее состояние процесса.Это именно то, что Асбьерн Ульсберг упоминает, говоря о доступности и конечных автоматах .Исходя из схемы места и соответствующих мест на этом плане, которые на самом деле являются кнопками или изображениями, на которые вы могли бы нажать, вы знали, для чего нужны эти виджеты, и вы каким-то образом знаете, что произойдет, если вы нажмете на одно из мест.В этом и заключается доступность .Видя это, вы знаете, что вы можете с этим сделать.
Концепция взаимодействия, изложенная выше, должна быть взята и переведена в REST.Как клиент, вам не нужно знать структуру URI, все, что вам нужно знать, это то, какие места доступны и что происходит, когда вы нажимаете определенные ссылки.Обычно это делается в REST через имена отношений ссылок, которые придают упомянутой ссылке некоторый семантический контекст текущему состоянию ресурса, который клиент только что получил.Такие отношения ссылок могут показаться априорным знанием, необходимым клиенту, что немного противоречит REST, поскольку REST пытается отделить клиентов от серверов, чтобы последний мог свободно развиваться, не рискуя потерять клиентов, хотя и как ссылка.отношения должны быть стандартизированы или основаны на расширениях , таких как dublin-core или других микроформатах .Совершенствование стандартов приведет либо к широкому принятию и поддержке со стороны разных клиентов, либо к механизмам, позволяющим в дальнейшем включать эти знания в клиента.В целом это позволяет избежать так называемых внешних потоков информации или процессов, которые вынуждают искать руководство по использованию этой системы.
Описанный выше подход будет использовать собственный ресурс резервирования, который уникально уникален.создается при «входе» в резервирование, которое сохраняется до вызова шага заказа.Этот ресурс резервирования отслеживает зарезервированные места, выбранные пользователем до сих пор.Считает ли система зарезервированные места другими пользователями занятыми или нет, это деталь реализации.Можно либо использовать систему «первым пришел», либо более вежливую, которая гарантирует резервирующему его места, пока не истечет некоторый льготный период и пользователь не закажет их.Это создает хорошее впечатление, что такие ресурсы могут быть нестабильными и просто быть частью определенного процесса.
Что касается использования GET, POST или других методов HTTP, веб-страница, которая отправляет вас на страницу бронирования, покажет вам форму, содержащую все места в месте проведения. Поскольку HTML поддерживает только GET или POST, последний вариант является наиболее подходящим. В API REST или HTTP вы можете использовать PUT. Возможно, сервер уже назначил вам определенную уникальную ссылку «резервирование», которую вы можете просто вызвать с помощью PUT. Если ресурс бронирования еще не существует, он будет создан для вас, если он существует, весь контент будет просто обновлен. Особенно, когда вы имеете дело с оговорками и денежными потоками , вы хотите использовать идемпотентные методы, такие как PUT.
Надеюсь, я мог бы дать вам несколько идей о том, как вы могли бы спроектировать свою систему бронирования, позволив серверу обучить клиента всему, что ему нужно знать, чтобы выполнить свою задачу.