Я начинаю проект с использованием архитектуры Restful, реализованной на Java (с использованием нового стандарта JAX-RS)
Мы планируем разработать графический интерфейс с помощью приложения Flex. Я уже обнаружил некоторые проблемы с этой реализацией с использованием компонента HTTPService (коды ошибок ответа, доступ к заголовкам ...).
У любого из вас есть опыт работы в подобном проекте. Насколько это возможно?




Возможности Flex работать как чистый RESTful-клиент имеют определенные недостатки.
Комментарии ниже взяты из этого блог:
The problem is HTTPService class has several major limitations:
- Only GET and POST methods are supported out of the box (unless you use FDS and set useProxy attribute to true)
- Not able to set request headers and there is no access to response headers. Therefore I am not able to access the response body in the case of an error.
- It HTTPService gets a status code anything other 200, it consider an error. (event 201, ouch!!). The FaultEvent doesn’t provide information about the status code any response body. The Flex client will have no idea what went wrong.
Мэтт Рэйбл также дал хорошая презентация на REST с Rails, Grails, GWT и Flex, на который есть ссылки на несколько хороших ссылок.
Осуществимо это или нет, на самом деле зависит от того, насколько вы готовы работать с прокси и т. д.
Фактически мы уже использовали Flex с Rest-Style Framework. Поскольку mbrevort уже упоминал, методы PUT и DELETE не могут использоваться напрямую. Вместо этого мы выполняем PUT через POST, а для DELETE мы используем GET для ресурса с параметром URL, например? Action = delete.
Это не стиль 100% Rest, поэтому я не уверен, работает ли он с реализацией JSR 311. Вам понадобится некоторая гибкость на стороне сервера, чтобы обойти ограничения PUT и DELETE.
Что касается обработки ошибок, мы реализовали службу ошибок. В случае ошибки на стороне сервера приложение Flex может запросить эту службу ошибок, чтобы получить фактическое сообщение об ошибке. Это также гораздо более гибко, чем просто сопоставление кодов возврата HTTP со статическими сообщениями.
Однако благодаря ECMA-сценариям Flex работать со службами REST на основе XML очень просто.
это RPC через HTTP и даже близко не к REST
Ну, на самом деле, что-то среднее между ними. REST имеет 4 метода, и два из них должны быть реализованы по-разному, поскольку требуемые HTTP-команды недоступны.
Да, я смог использовать POST и получить доступ к заголовкам с этим компонентом:
Сейчас я работаю над приложением, которое в значительной степени полагается на вызовы REST между Flex и сервлетами JavaScript и Java. Мы обходим проблему с кодом ошибки ответа, установив соглашение о блоке <status id = "XXX" name = "YYYYYY">, который возвращается при ошибке, с идентификаторами ошибок, которые примерно соответствуют кодам ошибок HTTP.
Мы обходим ограничения межсайтового скриптинга, используя Java-сервлет в качестве HTTP-прокси. Вызов прокси-сервера (который работает на том же сервере, который обслуживает остальное содержимое, включая содержимое Flex, отправляет запрос другому серверу, а затем отправляет ответ обратно исходному вызывающему.
Как многие отмечали, HTTPService немного упрощен и не делает всего того, что вам нужно. Однако HTTPService - это просто сахар поверх классов flash.net.*, таких как URLLoader, URLRequest и URLRequestHeader. Используя их, вы можете собрать большинство HTTP-запросов.
Когда дело доходит до поддержки других методов, кроме GET и POST, проблема в основном заключается в том, что некоторые браузеры (например, Safari) не поддерживают их, а Flash Player полагается на браузер во всех своих сетевых действиях.
Проблема здесь в том, что многим веб-дискуссиям по этому поводу посвящен год или больше. Я работаю над этим же исследованием прямо сейчас, и это то, что я узнал сегодня.
Этот Статья IBM Developer Works от августа 2008 г. от Хорхе Расилло и Майка Берра показывает, как создать интерфейсное приложение Flex / серверное приложение RESTful (примеры на PHP и Groovy). Хорошая статья. В любом случае, вот вывод:
// Flex doesn't know how to generate an HTTP DELETE.
// Fortunately, sMash/Zero will interpret an HTTP POST with
// an X-Method-Override: DELETE header as a DELETE.
deleteTodoHS.headers['X-Method-Override'] = 'DELETE';
Что тут происходит? веб-сервер IBM перехватывает и интерпретирует "POST with DELETE" как DELETE.
Итак, я копал дальше и нашел этот публикация и обсуждение с Доном Боксом (один из первых разработчиков SOAP). По-видимому, это довольно стандартное поведение, поскольку некоторые браузеры и т. д. Не поддерживают PUT и DELETE, и это временное решение. Вот отрывок, но обсуждения гораздо больше.
"If I were building a GData client, I honestly wonder why I'd bother using DELETE and PUT methods at all given that X-HTTP-Method-Override is going to work in more cases/deployments."
Мой вывод из этого заключается в том, что если ваша веб-сторона поддерживает этот заголовок X-Method-Override, вы можете использовать этот подход. Комментарии Don Box заставляют меня думать, что он довольно хорошо поддерживается, но я еще не подтвердил это.
Другая проблема возникает из-за возможности читать заголовки HTTP-ответа. Опять же, из сообщение в блоге Натана де Вриса в 2007 г. мы видим, что это обсуждается. Он продолжил эту запись в блоге и обсуждение своим собственным комментарием:
"The only change on the web front is that newer versions of the Flash Player (certainly those supplied with the Flex 3 beta) now support the responseHeaders property on instances of HTTPStatusEvent."
Я надеюсь, что теперь это не проблема.
Я думаю, также важно спросить себя, теряют ли клиенты, использующие «X-HTTP-Method-Override», некоторые преимущества REST. Действительно ли этот подход отличается от туннелирования через HTTP? Не теряете ли вы возможность использовать кеширующие прокси и другие подобные преимущества?
Если вы посмотрите здесь w3.org/Protocols/rfc2616/rfc2616-sec13.html в разделе 13.10, вы увидите, что PUT, DELETE и POST приводят к тому, что запись кэша становится недействительной. Поэтому независимо от того, используете ли вы правильный глагол или POST плюс X-HTTP-Method-Override, вы будете иметь одинаковый эффект на кеш.
@Gili Отвечая на ваш первый вопрос, нет, вы не теряете никаких преимуществ REST.
ОТДЫХ - это больше идеология, чем что-либо еще. Вы идете на презентации REST, и у них есть диспенсеры Coolaide.
Для приложений Flex развертывание стека в сочетании с маршалингом данных BlazeDS и AMF более удобно и производительно.
Вау, отлично, расскажи подробнее. Я люблю Кулаида. Кстати, "более производительный", чем что?
Раньше я справлялся с этим путем использования прокси-сервера PHP, который обрабатывает вызовы удаленных веб-служб и возвращает клиенту RTU JSON.
Я работал над заменой компонента HTTPService с открытым исходным кодом, который полностью поддерживает REST. Если интересно, вы можете найти бета-версию (исходный код и / или скомпилированную общую библиотеку времени выполнения Flex) и инструкции здесь:
Может быть, новый flex 4 - это ответ http://labs.adobe.com/technologies/flex4sdk/
RestfulX решил большинство / все проблемы REST с Flex. Он поддерживает Rails / GAE / Merb / CouchDB / AIR / WebKit, и я уверен, что было бы несложно подключить его к вашей реализации Java.
Дима также интегрировал в него библиотеку AS3HTTPClient.
Проверьте это!
Короткий ответ - да, вы можете выполнять RESTful с Flex. Вам просто нужно обойти ограничения Flash-плеера (лучше с последними версиями) и ограничения HTTP-стека браузера.
Мы занимаемся разработкой клиентов RESTful в Flex более года после решения основного заголовка HTTP-запроса и отсутствия PUT и DELETE с помощью подхода rails-esque? _Method =. Возможно, это безвкусно, но он выполняет свою работу.
Я заметил некоторые проблемы с заголовками в старом сообщении в блоге на http://verveguy.blogspot.com/2008/07/truth-about-flex-httpservice.html
нечеткое: вы упускаете суть. хак _method = необходим для работы с браузерами (и Flash Player), которые не могут выполнять настоящие вызовы PUT и DELETE. Rails использовал тот же обходной путь ...
Книга Гибкие рельсы может быть полезна - это отличный ресурс о том, как использовать Flex в качестве клиента RESTful. Хотя он ориентирован на использование Flex с фреймворком Rails, я считаю, что эти концепции применимы к любому фреймворку RESTful. Я использовал эту книгу, чтобы быстро освоить Flex с REST.
Поддержка REST в Flex в лучшем случае слабая. Я потратил много времени на создание прототипа, поэтому знаю большинство проблем. Как упоминалось ранее, из коробки есть поддержка только GET и POST. На первый взгляд кажется, что вы можете использовать конфигурацию прокси в LiveCycle Data Services или Blaze, чтобы получить поддержку PUT и DELETE. Однако это подделка. Запрос, исходящий от вашего приложения Flex, по-прежнему будет POST. Прокси-сервер преобразует его в PUT или DELETE на стороне сервера, чтобы обмануть ваш серверный код. Есть и другие проблемы. Есть мнение, что это лучшее, что могла придумать Adobe. После моей оценки мы решили пойти в другом направлении.
Я работаю над большим гибким проектом для Франклина Кови. Мы пользуемся услугами REST. Чтобы поддержать это. Мы создали оболочку XMLHttpRequest. Используя внешний интерфейс с некоторыми обработчиками событий. Мы открыли исходный код библиотеки. Вы можете проверить это на https://github.com/FranklinCovey/AS3-XMLHttpRequest
Если эти ограничения верны, Flex не подходит для REST через http. Возможность доступа ко всем заголовкам HTTP имеет решающее значение.