Что я не понимаю о REST?
Ваша проблема в том, что вы неправильно поняли цель сервлета . Он намерен действовать по HTTP-запросам, не более того. Вам нужна только фоновая задача, которая выполняется один раз на ежедневной основе.
Доступен EJB? Используйте @Schedule
Если ваша среда поддерживает EJB (например, WildFly, JBoss AS / EAP, TomEE, GlassFish и т. Д.), Тогда используйте @Schedule .
@Singleton
public class BackgroundJobManager {
@Schedule(hour="0", minute="0", second="0", persistent=false)
public void someDailyJob() {
// Do your job here which should run every start of day.
}
@Schedule(hour="*/1", minute="0", second="0", persistent=false)
public void someHourlyJob() {
// Do your job here which should run every hour of day.
}
@Schedule(hour="*", minute="*/15", second="0", persistent=false)
public void someQuarterlyJob() {
// Do your job here which should run every 15 minute of hour.
}
}
Да, это действительно все. Контейнер автоматически подберет и управляет им.
EJB недоступен? Используйте ScheduledExecutorService
Если ваша среда не поддерживает EJB (то есть не настоящий Java EE-сервер, например Tomcat, Jetty и т. Д.), Используйте ScheduledExecutorService . Это может быть инициировано ServletContextListener . Вот пример kickoff:
@WebListener
public class BackgroundJobManager implements ServletContextListener {
private ScheduledExecutorService scheduler;
@Override
public void contextInitialized(ServletContextEvent event) {
scheduler = Executors.newSingleThreadScheduledExecutor();
scheduler.scheduleAtFixedRate(new SomeDailyJob(), 0, 1, TimeUnit.DAYS);
scheduler.scheduleAtFixedRate(new SomeHourlyJob(), 0, 1, TimeUnit.HOURS);
scheduler.scheduleAtFixedRate(new SomeQuarterlyJob(), 0, 15, TimeUnit.MINUTES);
}
@Override
public void contextDestroyed(ServletContextEvent event) {
scheduler.shutdownNow();
}
}
Если классы заданий выглядят следующим образом:
public class SomeDailyJob implements Runnable {
@Override
public void run() {
// Do your daily job here.
}
}
public class SomeHourlyJob implements Runnable {
@Override
public void run() {
// Do your hourly job here.
}
}
public class SomeQuarterlyJob implements Runnable {
@Override
public void run() {
// Do your quarterly job here.
}
}
Никогда не думайте об использовании java.util.Timer / java.lang.Thread в Java EE
Никогда не используйте java.util.Timer и / или java.lang.Thread в Java EE. Это рецепт неприятностей. Подробное объяснение можно найти в этом ответе JSF по одному и тому же вопросу: Истеризация потоков в управляемом компоненте JSF для запланированных задач с использованием таймера .
7 ответов
я блокирующий меня из использования в своих интересах некоторого стандарта, если я' не использую их?
Вы самостоятельно блокируете из стандарта HTTP. Конечно, можно использовать, ЗАСТАВЛЯЮТ параметры делать то же самое. Это - просто не REST затем, но что-то Подобное RPC.
май я предлагаю книгу УСПОКОИТЕЛЬНЫЕ веб-сервисы Leonard Richardson и Sam Ruby? Это довольно забавно читать и показывает различия между разными подходами.
Для ответа на вопросы в немного большем количестве деталей: Вам решать, какой путь Вы идете. В теории можно сделать весь одинаковый материал и с УСПОКОИТЕЛЬНЫМИ и с подобными RPC подходами. С УСПОКОИТЕЛЬНЫМ Вы используете базовый протокол HTTP, чтобы быть протокол. С RPC Вы используете HTTP в качестве средства транспортировки и скрываете заказы на работу где-нибудь в транспортируемых данных. Это приводит к (необязательным) издержкам.
Только посмотрели на два из Ваших примеров:
- /books.php? action=add& title=AdvancedRuby& описание =....& securityId=923847203487
- /books.php? action=delete& id=342& securityId=923847203487
- Там является POST и ПОМЕЩЕННЫЙ, или УДАЛИТЕ, почему имеют action=add и action=delete?
- существует Аутентификация HTTP. Почему изобретают - возможно менее безопасный - securityId?
- BTW: Вы не должны позволять изменения в данных через, ДОБИРАЮТСЯ. Это - просто что-то, что не должно быть сделано (другая тема, хотя ;))
Я предполагаю, что Вы читаете этот сообщение Roy Fielding.
выделение А:
-
А REST API должен потратить почти все свое описательное усилие в определении типа (типов) среды, используемого для представления ресурсов и управления состоянием приложения, или в определении расширенных имен отношения и/или поддерживающей гипертекст разметки для существующих стандартных типов среды. Любое усилие потратило описание, какие методы использовать на том, какой URIs интереса должен быть полностью определен в рамках правил обработки для типа среды (и, в большинстве случаев, уже определенный существующими типами среды). [Отказ здесь подразумевает, что внеполосная информация управляет взаимодействием вместо гипертекста.]
-
А REST API не должен определять зафиксированные имена ресурса или иерархии (очевидная связь клиента и сервера). Серверы должны иметь свободу управлять их собственным пространством имен. Вместо этого позвольте серверам сообщать клиентам о том, как создать соответствующий URIs, тот, который сделан в HTML-формах и шаблонах URI путем определения тех инструкций в типах среды и ссылочных отношениях. [Отказ здесь подразумевает, что клиенты принимают структуру ресурса из-за из информации о полосе, такой как проблемно-ориентированный стандарт, который является ориентированным на данные эквивалентом функциональной связи RPC].
, конечно, можно быть успешным использованием подобного RPC подхода, как Вы описываете, и легче схватить, чем 'надлежащий REST API'. Самый недооцененный аспект REST - то, что, когда-то определенный, он должен автоматически работа , Вы не должны определять, переходят к этому URI с помощью этого метода для получения того ответа, который должен все подразумеваться типами среды, которые Вы обеспечиваете плюс средство сообщить клиентам, где найти соответствующие ресурсы.
От RestWiki:
- А ДОБИРАЮТСЯ до средств идентификатора, "Дают мне копию Вашей информации в конкретном формате документа".
- А, ПОМЕЩЕННЫЕ в то средство идентификатора ", Заменяют Вашу информацию моей".
- POST добавляет, что информация, и
- УДАЛЯЕТ, устраняет информацию.
Принимая это во внимание, применение его к Вашему приложению должно быть довольно простым.
REST является интересной и потенциально полезной технологией, но к сожалению это, кажется, притягивает самый педантичный набор разработчиков.
кажется, что они быть бы реализация следовать за остальными догма к букве даже при том, что это означает общую сумму убытков функциональности. Любое отклонение от чистого REST будут рассматривать как ересь.
С платформой Restlet мы точно пытались обеспечить этот уровень абстракции выше деталей HTTP и сделать понятия REST более конкретными (у многих есть класс соответствия как Компонент, Коннектор и Представление): http://www.restlet.org/
Мы - прагматически настроенные кодеры, и наши пользователи разрабатывают реальные приложения с нашей УСПОКОИТЕЛЬНОЙ платформой (для Java и GWT). Сторонники REST не все педантичны, но существует кривая обучения как для каждой главной технологии.
Я ничто не нахожу успокоительным о REST. Мне это - большое понятие с абстрактной точки зрения для веб-фанатов, которые не должны заниматься более песчаными проблемами кодирования, вовлеченными в сложную Связь HTTP.
Wouldn'd это быть хорошим, если API REST был доступен, который абстрагировал нас от всего HTTP. Но это не делает. Вместо этого сторонники REST должны сделать, работа в сфере торговли Вам пишет такой API со всеми сопутствующими проблемами отладки и тестирования.
день я вижу заголовок REST 1.0, я брошу второй взгляд для нахождения преимущества стоящим усилия.
Я попробую посмотреть, как это может выглядеть RESTful.
/books.php?category=ruby
GET /search?type=books&category=ruby
/books.php?id=23
GET /books/23 (or /books/23.xml)
/ books.php? action = add & title = AdvancedRuby & description = .... & securityId = 923847203487
POST /books
title=AdvancedRuby&description=A+great+book...
/books.php?action=delete&id=342&securityId=923847203487
DELETE /books/342
Многие разработчики придерживаются GET и POST, и в этом случае последний может быть :
POST /books/342
status=Deleted