Совет для noob: Рестлет или SOAP

Question

Мне нужно разработать веб-сервис, который выглядит следующим образом: я выполняю вызов get, включая строку в URL, и мне нужно получить другую строку на основе исходной строки из запроса.

Возможно, мне придется делать этот звонок даже тысячи раз в минуту. Вы думаете, что сервер сможет обрабатывать так много HTTP-коммуникаций? Подход RPC лучше?

Любые предложения приветствуются, я только начинаю работать над веб-сервисами и не имею понятия о производительности.

Спасибо.

Answer 1

Тысячи звонков в минуту означает сотни в секунду. Я считаю, что современные компьютеры могут сделать больше. Я не думаю, что у вас будут серьезные ограничения производительности. Но прежде чем начать, проверьте, сколько времени займет обработка запроса. Если это займет время, я бы порекомендовал вам отделить интерфейс HTTP WEB и бизнес-логику, то есть обработать запрос асинхронно. Вы можете легко достичь этого, используя JMS.

МЫЛО или ОТДЫХ? Я лично предпочитаю ОТДЫХ. Это проще, это быстрее. И кажется, что у вас есть только 2 параметра String, поэтому SOAP не дает вам никаких преимуществ.

Answer 2

Вы также можете проверить Джерси на http://jersey.java.net/ в качестве альтернативы рестлету.

Answer 3

Одним из ключевых преимуществ веб-службы REST является то, что ее ответы можно кэшировать.Таким образом, промежуточная цепочка кеша HTTP между вашим сервисом и его клиентами несет огромную часть общей рабочей нагрузки, поэтому ваш веб-сервис может расширяться.REST может быть гораздо более масштабируемым, чем SOAP или RPC.

Answer 4

ИМХО, основное различие между SOAP и REST заключается в том, что первый вводит дополнительные издержки (как обработки, так и данных), поскольку его данные должны следовать несколько строгой структуре. REST проще и удобнее, поскольку не требует явного определения формата сообщения, оставляя эту задачу программному обеспечению, которое будет обрабатывать сообщение, а не транспортной инфраструктуре.

Итак:

• Хотите ли вы внедрить структуру сообщений за счет дополнительных издержек? Используйте SOAP;
• Вам нужен более легкий вариант за счет того, что отправители и получатели объединяют сообщения в значимые данные? Используйте REST;