#rest #restful-architecture #restful-url #discoverability
#rest #restful-архитектура #restful-url #возможность обнаружения
Вопрос:
При предоставлении веб-службы Restful (на Java) есть ли способ раскрыть, какие методы и их параметры внутри службы, как в службе soap wsdl?
Как потребляющая сторона веб-службы узнает, какие доступные методы могут быть использованы? (Я хочу использовать веб-сервис только через его URL).
Я использую NetBeans 8.0.2 с Apache Tomcat.
Спасибо в расширенном.
Ответ №1:
Рассматривая модель зрелости Ричардсона, REST речь идет о том, Resources какие HTTP Verbs (а не «методы») могут быть применены, обнаружены / раскрыты через Links . Например, на верхнем уровне вашего API клиент может заметить products-query связь, которая будет извлекать список ресурсов продукта после доступа через GET запрос — и так далее.
Другой способ добиться этого — подключить Swagger поверх вашего API.
Ответ №2:
Как @Alexandru указал на модель зрелости Ричардсона, для истинной службы RESTful или клиента последний уровень (обычно 3, начинающийся с индекса 0) уже должен быть на месте, иначе это не «истинный» RESTful.
Основная идея, лежащая в основе REST, заключается в разделении распределенных клиентов и серверов, аналогично веб-браузерам, которые полностью не связаны ни с какими веб-серверами. Также, подобно традиционному веб-сеансу, когда вы начинаете с определенной начальной страницы, а затем переходите по страницам с помощью ссылок, то же самое относится и к содержимому RESTful, где вы начинаете с некоторого базового ресурса, а затем используете возвращенные URI для перехода к новым ресурсам.
Каждый URI начинается с идентификатора протокола, который определяет возможные действия или методы, которые могут быть выполнены на указанном ресурсе. Чаще всего это будет HTTP, но он не ограничивается им и может также использовать что-то вроде mailto, FTP или что-то в этом роде. Следовательно, соответствующая спецификация протокола также является документацией о возможных действиях.
Параметры, которые необходимо передать в URI, либо уже заданы в ответе на предыдущий запрос, либо могут быть шаблонными и, следовательно, устанавливаться клиентом динамически. Здесь клиенту необходимо понять, как обрабатывать шаблоны и откуда брать возможные значения. Однако это также может быть включено в ответ, подобно веб-формам, где определенные варианты выбора также предоставляются сервером. Соответствующий тип носителя (т. Е. application/atom xml или application/hal json ) поддерживает клиента при обработке данных, придавая контенту большую семантическую ценность и, возможно, даже определяя определенную структуру, которую цель может использовать для упрощения своей работы.