Альтернатива созданию правильного веб-сервиса для приложения iPhone для потребления - PullRequest
4 голосов
/ 21 апреля 2011

Я занимаюсь разработкой приложения для iPhone для клиента.Помимо прочего, приложение позволит пользователям просматривать и размещать заказы по конкретным (материальным) продуктам.

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

На сайте регистрация и аутентификация пользователя, а также размещение заказа осуществляется через POST-запросы по безопасному HTTP.Ответом всегда является отформатированная HTML-страница, которая будет содержать строки, указывающие, был ли запрос успешным или нет, и если произошла ошибка, что это за ошибка и т. Д.

Поэтому при условии, что я могу реплицировать запросы POST нателефон и анализ HTML-ответов, чтобы прочитать результаты каждого запроса, вы думаете, это приемлемая альтернатива созданию веб-службы для обработки этого?

Помимо возможности изменения страниц (которой мы можем управлять) и того факта, что мне, вероятно, придется загружать и анализировать относительно большой HTML-ответ, есть ли другие недостатки этого решения и есть ли что-то еще?что мне может не хватать?

Большое спасибо заранее за ваши мысли.Ура, Рог

Ответы [ 6 ]

12 голосов
/ 21 апреля 2011

Вы можете создать сервер-посредник, который будет взаимодействовать с клиентским сервером, и предоставлять на нем некоторые веб-службы REST с ответами json (небольшая нагрузка и простота обработки), которые будут использоваться приложением iPhone.

6 голосов
/ 27 апреля 2011

Итак, вы собираетесь анализировать HTML и формулировать POST со стороннего сервера и молиться, чтобы они даже не переименовывали поле формы.

Ваш вопрос состоит из двух частей:

  1. Считаю ли я, что чудо является приемлемым решением? Я не знаю.
  2. Думаю ли я, что помимо того, что требуется чудо, есть ли другие недостатки? Ни о чем я не могу думать.

Вы не спрашивали, но это ужасный ход действий. Два предложения.

  1. Я предполагаю, что поставщики сторонней платформы не заинтересованы во включении сторонних приложений путем предоставления API. У них есть очень веская деловая причина для этого, заключающаяся в том, что это способствует блокировке платформы. Обратитесь в их службу поддержки и поговорите с ними.

  2. Вы должны продать клиента при создании посреднического веб-сервиса. Чтобы хотя бы попытаться уменьшить ущерб, который могут оказать изменения в вашей сторонней платформе для вашего приложения, я рекомендую вам создать и использовать прокси-сервер, который получает запросы от ваших приложений и передает их на стороннюю платформу. Вы должны встроить в этот протокол клиент-сервер средство для возврата сообщений «мы в режиме обслуживания, уходите» в приложения, в тот неизбежный день, когда сторонний сервер изменяет что-то, что нарушает работу вашего приложения (они меняли биллинг и доставку адрес страницы, например), и вам нужно спешить через обновление через Apple, чтобы справиться с ним.

Прокси-сервер может быть написан в более гибком и простом виде, например PHP, Python, Perl или Ruby. Он может быть размещен на Amazon в микроэкземпляре.

p.s. Этот вопрос неуместно помечен как цель C.

1 голос
/ 30 апреля 2011

Не ищите решение для парсинга на iPhone по 4 причинам:

  • Сервер может изменить свой дизайн и сломать ваше приложение (отправка в AppStore длинная) + Они также могут обнаружить, что запросотправляются из приложения на основе пользовательского агента, которому необходимо обновить приложение, чтобы изменить его.
  • Некоторые запросы могут быть выполнены через Javascript, поэтому вам придется не только анализировать (X) HTML, но и запрос Javascript(который может быть в форме XMLHttpRequest, но не обязательно)
  • Долгосрочная эволюция рынка мобильной связи: возможно, ваш клиент захочет (или захочет) приложение для Android, Blackberry, Bada OS (Samsung), Symbian (Nokia / OVIStore), Java Mobile или Windows Phone 7?
  • Конечно, сетевой трафик, память и процессор необходимы для анализа HTML (посмотрите, сколько времени требуется браузеру, чтобы это сделать?)

Что касается трафика, если приложение не будет иметь большой трафик, вы можете разместить свой прокси-сервер в своем доме.Или вы можете найти какого-нибудь провайдера, чтобы разместить его для вас.Я думаю, вам не нужно больше, чем пара мегабайт памяти, но, возможно, трафик.Менее чем за 100 € / год вы можете найти некоторые с неограниченным трафиком (например, план OVH Pro или Infomaniak).Но если вы хотите перейти на Java, взгляните на Google App Engine: вы платите, только если ваш трафик важен и если ваше приложение генерирует много циклов ЦП.Если нет: вам не нужно платить.И он размещен на сервере Google: надежный.

1 голос
/ 24 апреля 2011

Я думаю, что использование веб-языка JSON будет способствовать сокращению времени анализа.Создав службу REST, которая при отправке запроса GET возвращает правильную информацию для легкой сортировки, вы могли бы затем отобразить вывод намного быстрее, чем при анализе прямого HTML.

Я предпочитаю JSON, а не XML, ноу каждого свои предпочтения.Вам следует взглянуть на несколько очень хороших библиотек, которые созданы специально для анализа XML и JSON.

Для XML я рекомендую использовать встроенный синтаксический анализатор libxml.Хотя иногда это может показаться очень сложным в использовании.Простой поиск в Google выдаст кучу результатов, которые конкретно связаны с тем, какой синтаксический анализатор следует использовать, в зависимости от того, какую задачу нужно выполнить.

Что касается синтаксического анализатора JSON, я рекомендую SBJSON ,В настоящее время я использую один из самых крупных проектов, которые я предпринял, и он определенно отлично работает для моего использования.

Если вам нужен хороший способ подключения к веб-сервису RESTful, вам следует попробовать LRResty.

1 голос
/ 23 апреля 2011

HTML является худшим из-за синтаксического анализа (1-2 секунды на страницу), памяти и изменений, но вы уже это знаете. Заранее убедитесь, что ВСЕ данные, которые вам нужны, отображаются в HTML.

Если вы используете сервер-посредник, вы перемещаете работу в другое место и у вас есть другой сервер для обслуживания. Я бы сделал это, только если память является проблемой. Проверьте Как выбрать лучший анализатор XML для вашего iPhone проекта для поддержки памяти / производительности / xpath. libxml2 - хороший вариант, но он зависит от ваших потребностей. И, возможно, вы захотите проверить функции ASIHTTPRequest перед использованием SDK.

0 голосов
/ 27 апреля 2011

Если клиент открыт, вы можете рассмотреть PayPal API .

...