Ajax и REST, Часть 1

Преимущества архитектурного стиля Ajax/REST для иммерсивных Web-приложений

Чем более иммерсивными становятся серверные Web-приложения, используя модели нескольких приложений и предоставляя персонифицированное содержимое, тем больше их архитектура нарушает Representational State Transfer (REST), архитектурный стиль Web. Эти нарушения могут снизить универсальность приложения и увеличить сложность системы. Достигая равновесия с REST, архитектура Ajax позволяет иммерсивным Web-приложениям устранить эти негативные воздействия и приобрести желаемые качества REST.

Билл Хиггинс, Разработчик продуктов Rational, IBM

Билл Хиггинс (Bill Higgins) работает в отделе IBM по разработке разумного ПО, где он занимается инструментами для поддержки команд разработчиков. Билл окончил Университет штата Пенсильвания в 2000 г., получив звание бакалавра наук в теории вычислительной техники. Билл любит проводить свободное время с женой и двумя детьми, размещать информацию на своем блоге developerWorks, читать, играть в баскетбол.



02.10.2006

Всего за 15 лет сеть World Wide Web разрослась, превратившись из исследовательского эксперимента в один из технических столпов современного мира. Изначально предназначенный для обеспечения легкого размещения и возможности ссылаться на информацию, Web также стал жизнеспособной платформой для приложений ПО. Но, по мере возрастания иммерсивности приложений посредством использования моделей нескольких приложений и генерации персонифицированного содержимого, их архитектура стала все больше нарушать Representational State Transfer (REST), архитектурный стиль Web. Эти нарушения снижают универсальность приложения и усложняют системы.

Появление клиентского архитектурного Web-стиля Ajax позволяет иммерсивным Web-приложениям добиться соответствия архитектурному стилю REST. Они могут приобрести желаемые качества REST, устранив нежелательные характеристики, появляющиеся при нарушении приложением принципов REST. Данная статья объясняет, как и почему Ajax и REST успешно взаимодействуют в иммерсивных Web-приложениях.

Посетите Центр Ресурсов Ajax, орган для комплексного информационного обслуживания модели программирования Ajax, предоставляющий статьи и учебники, дискуссионные форумы, блоги, вики (wikies), сводки событий и новостей. Если что-то произойдет, всю информацию вы найдете здесь.

REST: Архитектура Web

Несмотря на то, что World Wide Web создавался на протяжении десятилетий научных исследований, его действительное рождение произошло в декабре 1990 года, когда Тим Бернерс-Ли закончил разработку прототипов для основных компонентов Web: унифицированных идентификаторов ресурсов (URI), HTTP, HTML, браузера и сервера. Всеобщий прием Паутины превзошел все его ожидания автора. В своем знаменитом сочинении (см. Ресурсы) Рой Филдинг описывает настроения того времени:

"Ликуя по поводу успеха, сообщество разработчиков Интернет, тем не менее, было обеспокоено тем, что быстрый рост использования Web, наряду с некоторыми недостаточными сетевыми характеристиками первых версий HTTP, скоро опередит возможности внутренней структуры Internet и приведет к общему краху."

"Дизайн архитектуры имеет набор характеристик, позволяющих ей соответствовать или превышать системные требования. Незнание этих характеристик приводит впоследствии к изменениям, нарушающим архитектуру, подобно тому, как замена несущей стены большой оконной рамой может нарушить устойчивость конструкции здания. " -- Рой Филдинг

Филдинг и другие разработчики пересмотрели архитектуру Web и ее способность поддерживать массовое расширение и эксплуатацию. Практическим результатом этого повторного рассмотрения явилась модификация, обновление, таких важных стандартов, как URI и HTTP. Не столь заметным, но значимым результатом также было определение нового архитектурного стиля для приложений гиперсреды, названного Филдингом Representational State Transfer (REST). Филдинг утверждал, что компоненты, развернутые в Web, которые принимают и отвечают ограничительным условиям конструктивной разработки REST, будут наделены всеми желаемыми характеристиками Web. Он также предупреждал о том, что Web-компоненты, не отвечающие стандартным принципам REST, не смогут оценить эти преимущества.

Первое время большинство Web-сайтов и простых Web-приложений полностью соответствовало принципам REST. По мере возрастания иммерсивности Web-приложений их архитектура отклонялась от принципов REST, со всеми вытекающими отсюда последствиями. Проблему иммерсивных серверных Web-архитектур довольно сложно решить, поскольку десятилетие использования этого архитектурного стиля породило миф о том, что такие проблемы внутренне присущи архитектуре Web-приложений. Это не так. Скорее, их возникновение напрямую зависит от архитектурного стиля серверных Web-приложений. Чтобы сломать эти предубеждения, необходимо вспомнить изменения архитектуры, приведшие к настоящему положению дел. Это объяснит, почему многие предположения, принятые нами, более не являются верными и что удобно использоватьприложения Ajax.


Краткая история Web-приложений

Бернерс-Ли создал Web как средство обмена документами для научных сотрудников, позволяющее преодолевать большие расстояния и создавать простые ссылки между документами для распространения знаний и идей. Однако стандартные архитектурные характеристики URI быстро сделали возможным обмен не только статичными документами.

Web-сайты на основе статичных документов

Изначально содержимое Web представляло собой статичные HTML-документы со ссылками на другие статичные документы, как показано на Рисунке 1:

Рисунок 1. Web-сайт на основе статичных документов.
Web-сайт на основе статичных документов

REST делает получение статичных документов невероятно эффективным и варьируемым, поскольку их легко можно кэшировать по URI и по дате последнего изменения. Скоро разработчики отойдут от статичных документов и начнут поддерживать обслуживание динамического контента.

Первые динамические Web-приложения

Бернерс-Ли и другие спроектировали стандарт URI для поддержки универсальной идентификации ресурса, позволяя его представлению (HTML, текстовые и т.п.) изменяться на основе согласованности между Web-клиентом (обычно Web-браузер) и Web-сервером. Поскольку URI отличается от идентификации ресурса и лежащего в основе хранения ресурса механизма, разработчики Web могут создавать программы, изучающие синтаксис URI и создающие документ в процессе работы, комбинируя предопределенные элементы UI и динамически полученные данные, часто из реляционной БД (см. Рисунок 2). Хотя документы создаются, их кэшированные характеристики идентичны характеристикам статичных файлов.

Рисунок 2. Web-сайт, использующий записи БД, встроенные в код шаблона HTML
Web-сайт, использующий записи БД, встроенные в код шаблона HTML

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

  1. Пользователь вводит имя (например, Билл Хиггинс (Bill Higgins)) в форму Web и нажимает кнопку "Отправить".
  2. Форма создает URI на основе введенного имени и запрашивает содержимое этого URI через сервер (например, GET http://psu.edu/Directory/Bill+Higgins).
  3. Сервер рассматривает URI и создает Web-страницу с номером телефона и адресом студента.
  4. Сервер отсылает созданную страницу браузеру пользователя.

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

Иммерсивные Web-приложения

Следующее поколение Web-приложений целенаправленно разрабатывалось как высоко-иммерсивное, предоставляющее персонализированное содержимое и построенное на богатых приложениями моделях. В течение следующих 10 лет разработчики Web преуспели в создании этих иммерсивных приложений. Наиболее характерным примером таких приложений является сайт электронной коммерции Amazon.com. При взаимодействии пользователя с Web-приложением Amazon, оно создает набор типовых страниц, рекомендующих определенные товары, показывает историю поиска и выводит суммарную стоимость товаров в потребительской тележке пользователя.


Иммерсивные серверные приложения и REST

Иммерсивные Web-приложения, вне всякого сомнения, полезны, но стиль серверного иммерсивного Web-приложения в корне противоречит архитектурным принципам REST. В особенности он нарушает ключевое ограничение REST и упускает возможность воспользоваться преимуществом одного из наиболее важных достоинств REST, таким образом, создавая новый набор проблем.

Нарушение ограничений, налагаемых на адресный сервер без сохранения адресов

Ограничение REST, налагаемое на адресный сервер без сохранения адресов клиентов, запрещает сессионное состояние сервера. Проектирование с учетом этого ограничения повышает такие характеристики системы, как обзорность, надежность и универсальность. Но иммерсивные серверные Web-приложения стремятся обеспечить наибольшую персонификацию для каждого отдельного пользователя, поэтому им приходится выбирать между двумя технологиями, первая из которых характеризуется отправкой большого количества статичной информации по каждому клиентскому запросу, с тем, чтобы каждый запрос был контекстно-полным, а сервер не хранил адреса. Второе решение, кажущееся более простым, заслужило симпатии как разработчиков приложений, так и поставщиков промежуточного ПО. Оно заключается в том, чтобы отправить простой идентификатор пользователя и связать его с пользовательским сессионным объектом на сервере. (см. Рисунок 3). Вторая технология прямо нарушает ограничение, налагаемое на адресный сервер без сохранения адресов клиентов. Конечно, она делает возможной реализацию желаемой пользовательской функциональности (в особенности персонификацию), но вызывает огромную перегрузку архитектуры.

Рисунок 3. Иммерсивное серверное Web-приложение, содержащее большое количество серверных сессионных состояний
Иммерсивное серверное Web-приложение

Серверное приложение Java™ HttpSession API является примером такой перегрузки. HttpSession позволяет вам связывать сессионное состояние с конкретным пользователем. Начинающих разработчиков этот API привлекает кажущейся простотой. На самом деле, представляется, что в HttpSession можно хранить любой объект и извлекать его без программирования специальной логики поиска. Но, как только объектов, помещенных в HttpSession, становится больше, вы обращаете внимание на то, что сервер приложений использует все больше и больше ресурсов для хранения и обработки. Вскоре вы решаете развернуть ваше приложение в упорядоченной среде, чтобы решить проблему нехватки ресурсов. Затем вы понимаете, что HttpSession для работы в упорядоченной среде требуется, чтобы каждый объект реализовывал Упорядочиваемый интерфейс Java, для передачи сессионный данных от сервера к серверу в упорядоченной среде. Кроме того, вам необходимо решить, сохраняет ли сервер приложений сессионные данные в случае цикла "завершить/повторить". Вскоре вам приходит в голову, что нарушение ограничения, налагаемого на адресный сервер без сохранения адресов, было, возможно, не такой уж блестящей идеей. (На самом деле, многие разработчики не знают об этом ограничении.)

Запрет распределенного кэширования

Вторым серьезным недостатком иммерсивных серверных Web-приложений является практически полная невозможность использования первоклассной поддержки REST для кэширования ресурсов. Приведу слова Филдинга: "Преимущество добавления ограничений кэширования заключается в том, что потенциально они могут частично или полностью устранить некоторые действия по обмену данными, улучшая производительность, универсальность и воспринимаемый пользователем результат работы, уменьшая среднее время ожидания обмена данных. С другой стороны, кэш может снизить достоверность данных, если устаревшие данные в кэше значительно отличаются от тех, что были бы получены при пересылке запроса напрямую серверу."

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

Существует несколько решений проблем, связанных с не оснащенными кэшем ресурсами. Одним из них является создание серверного кэша с мелкомодульным хранением ресурсов, чтобы сервер мог построить крупномодульную страницу, монтируя заранее собранные части, а не из базовых элементов (HTML и данные). Но проблема остается: каждый запрос требует значительной обработки на сервере, снижая универсальность и потенциально увеличивая время ожидания ответа пользователем.

Другим следствием неспособности обслуживать оснащенные кэшем ресурсы будет необходимость явного запрета для высокодинамичных Web-приложенияй осуществлять запросы через поисковые машины и другие системы оптимизации выполнения запросов ("bot"), поскольку каждый запрос подразумевает требующую объемную обработку данных; в REST-приложении вы обработали бы ресурс один раз для каждого запроса и отправляли бы простое "не измененное" сообщение при последующих визитах.

Клиентская обработка без Ajax

По мере увеличения количества пользователей, обращающихся к Web-приложению, системе требуется больше ресурсов. Вы можете требовать, чтобы сервер делал больше, но вам понадобится более мощный сервер или группа объединенных серверов (а программы со стороны сервера не срабатывают в упорядоченной среде). Но, если передать обработку клиентам, с каждым новым пользователем вам придется поддерживать и загрузку на новый ПК. А, если передать сессионное состояние клиенту, тогда ваш сервер будет адресным сервером без сохранения адресов - желанное качество масштабируемого Web-приложения. Это кажется очевидным и не требующим анализа. Почему же тогда все иммерсивные Web-приложения не спроектированы таким образом? До создания Ajax ответ был прост: Потому что состояние приложения теряется каждый раз, когда пользователь посещает новую Web-страницу.

Каждый раз, посещая Web-страницу, вы загружаете один или несколько файлов, содержащих контент (данные и структурную информацию об их представлении, такую, как таблицы и списки) и стили, определяющие оформление контента (например, красный цвет текста). В Web-браузере эта информация рассматривается как абстрактное множество объектов документа. Например, рассмотрим следующий список:

  • Ford
  • BMW
  • Toyota

ваш браузер рассматривает этот HTML как объект "неупорядоченный список" , содержащий три элемента типа списка; каждый элемент списка содержит текст. Весь документ можно представить в виде сложной древовидной структуры взаимосвязанных объектов. Когда браузер переходит от одной страницы к другой, он удаляет объектную древовидную структуру текущей страницы и создает объектную древовидную структуру новой страницы.

Зачем потреблять так много ресурсов на перегруженном сервере, если теоретически вы могли бы разделить ресурсы памяти и необходимые для обработки ресурсы между клиентами? Ответ прост и заключается в том, что это не было осуществимо при данных ограничениях традиционных Web-браузеров (см. Клиентская обработка без Ajax). Архитектурный стиль Ajax позволяет разработчикам распределять требования по обработке и состоянию клиентам. Далее вы узнаете, почему иммерсивные приложения, построенные на основе архитектурного стиля Ajax, могут восстановить равновесие с REST и пользоваться его преимуществами.

Ajax и REST

Как вы узнали ранее, традиционные серверные Web-приложения комбинируют элементы представления и динамических данных на сервере и возвращают браузеру готовый документ HTML. Приложения Ajax отличаются тем, что большая часть их UI и логики приложения постоянно хранится в браузере; клиентское браузерное приложение считывает новые серверные данные по необходимости и вставляет их в текущую страницу (см. статью Джесси Джеймс Гаррет по конструкции Ajax в разделе Ресурсы). Размещение представления и привязки данных может показаться деталью реализации, но результатом этого небольшого отличия является создание совершенно разных архитектурных стилей.

Использование Web-клиента с сохранением сессионного состояния

Ajax-приложения часто описывают как Web-страницы, которым не требуется выполнять полное обновление страницы для каждого щелчка мышкой. Это описание точное, но в основе такого архитектурного решения лежит тот факт, что приложения с полным обновлением страниц снижают эффективность работы иммерсивного пользователя. Приложения с полным обновлением страниц выглядят еще более неприглядно с точки зрения архитектуры, поскольку не имеют функции хранения состояния приложения клиентом, что, в свою очередь, приводит к реализации проектных решений, препятствующих использованию приложениями преимуществ множества наиболее сильных проектных возможностей Web-архитектуры.

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

Кэширование в системе Ajax

Представьте себе, что Amazon.com было полностью перестроено как Ajax-приложение -- единая Web-страница, динамически получающая данные от сервера. (Едва ли Amazon захочет сделать это по причинам коммерческого плана, но это тема для отдельной статьи.) Поскольку большое количество UI и логики приложения теперь выполняется скорее клиентом, чем сервером, загрузка исходной страницы потребует загрузки Ajax-системы Amazon, как описано Гарретом. Эта система содержит группу логики приложения (выполненную как программа JavaScript) и каркас UI, наполняемый позднее коммерческими данными, полученными асинхронно с сервера (см. Рисунок 4):

Рисунок 4. Иммерсивное приложение Ajax
Иммерсивное приложение Ajax

Интересной характеристикой системы Ajax является то, что, хотя она объединяет в себе большое количество логики приложения и презентации элементов интегрированной среды, при грамотной разработке она не содержит коммерческих данных или персонифицированного контента. Приложение и представление приняли окончательный вид во время развертки. В обычном Web-окружении ресурсы приложения могут меняться раз в полгода. Это значит, что система Ajax, разделяющая ресурсы приложения и данных, является высококэшируемой.

Наглядным примером является инструментальный комплект Dojo (см. Ресурсы). Dojo оборудован инструментами времени создания для сжатого файла JavaScript, содержащего всю логику, представление и стили вашего приложения. Поскольку в конечном смысле это всего лишь файл, Web-браузер может его кэшировать, а это значит, что при повторном посещении Web-приложения, оснащенного инструментарием Dojo, вы скорее загрузите систему Ajax из кэша вашего браузера, чем с сервера. Сравните с высокоиммерсивными серверными Web-приложениями, где каждый запрос влечет за собой серверную обработку с существенными затратами ресурсов, поскольку браузер и сетевые посредники не могут кэшировать постоянно меняющиеся ресурсы.

Поскольку система приложения Ajax -- простой файл, она также может работать через прокси-сервер proxyable. В широкой корпоративной внутренней сети только один сотрудник может загрузить определенную версию приложения системы Ajax, а все остальные получают кэшированную копию из шлюза внутренней сети.

Итак, говоря о ресурсах приложения, хорошо спроектированное приложение Ajax отвечает принципам REST и имеет значительные преимущества по расширяемости, в отличие от серверных Web-приложений.

Кэширование данных Ajax

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

Возвращаясь к примеру об Amazon.com, представьте себе, что вам нужно перейти по ссылке для просмотра информации о книге по конструктивным шаблонам. В настоящем приложении Amazon.com, при щелчке по ссылке отсылается различная информация, определяющая запрашиваемый ресурс. Также отсылаются различные признаки сессионного состояния, что позволяет серверу создать новую страницу, включающую предыдущее сессионное состояние (например, просмотренные ранее элементы), персонифицированную информацию (например, "вы приобрели эту книгу в 1999 г."), и сам коммерческий ресурс, имеющийся на данный момент. Приложение очень динамично и высокоперсонифицировано -- но не может быть кэшировано и не является естественно расширяемым (хотя, на примере Amazon отлично видно, что эти архитектурные могут быть решены инфраструктурным конструированием, затраты на которое обходятся в миллионы долларов). Теперь рассмотрим то же действие, но только в (воображаемой) Ajax-версии данного приложения. Не требуется никакой обработки для отображения "просмотренных ранее элементов". Просто эта информация уже имеется на странице, которая не будет утеряна при переходе по ссылке. Могут быть сделаны следующие два запроса информации о книге по конструктивным шаблонам:

  • /Books/0201633612 (где 0201633612 -- код ISBN с номером издания)
  • /PurchaseHistory/0201633612/bhiggins@us.ibm.com

Первый гипотетический запрос возвращает информацию о книге (имя автора, название, описание и т.д.); он не содержит данных пользователя. Отсутствие данных пользователя означает, что чем больше пользователей запрашивает один и тот же ресурс, тем больше вероятность того, что они получат его кэшированные версии из промежуточных узлов в Интернет, а не данные с сервера-источника. Это снижает нагрузку на сервер и общую загруженность сети. Второй запрос, с другой стороны, содержит данные пользователя (Билла Хиггинса интересует распределение покупок во времени на эту книгу). Поскольку эти данные включают персонифицированную информацию, только один пользователь сможет получить и кэшировать данные с этого URI. Хотя эти персонифицированные данные не имеют универсальных характеристик, которыми обладают неперсонифицированные данные, важно то, что эта информация получена с определенного URL и, следовательно, имеет положительную характеристику: она не препятствует кэшированию другим приложением данных и не влияет на кэшируемые им ресурсы данных.

Ajax и (ошибко)устойчивость (robustness)

Другим преимуществом архитектурного стиля Ajax является способность легко справляться с неполадками сервера. Как было упомянуто выше, серверные Web-приложения с иммерсивным взаимодействием с пользователями имеют тенденцию хранить большое количество сессионных состояний клиентов на сервере. Если на сервере происходит ошибка, сессионное состояние пользователя теряется и нарушается работа его браузера ("Почему я вернулся на домашнюю страницу? И куда исчезли товары из моей тележки?"). В приложении Ajax, где клиент хранит сессионное состояние, а не сервисы, нарушение работы или перезагрузка сервера может пройти незамеченным для пользователя, поскольку сбой в работе сервера не влияет на сессионное состоянием, хранимое браузером пользователя; работа служб без сохранения сессионного состояния идемпотентна и определяется исключительно содержанием запросов пользователя.


Перспективы и трудности

Говоря о классе Web-приложений, которые я называю иммерсивными, нужно заметить, что хорошо спроектированные приложения Ajax/REST намного превосходят традиционные серверные Web-приложения по части опыта пользователя, быстроты реакции и универсальности. Однако, характеристики рабочего цикла не являются единственной составляющей успеха ПО и Web-приложения. Создание приложений Ajax/REST сопряжено с некоторыми серьезными проблемами, не связанными с рабочим цикло м, включая сюда и проблемы, связанные с массовыми разработками JavaScript, культурных проблем и проблем организации пакетов. В дополнительной статье я рассмотрю культурные проблемы, а решение остальных проблем оставлю моим коллегам по Ajax.

Спасибо за помощь

Я бы хотел выразить благодарность моим коллегам Крису Митчеллу, Джошу Стейгеру, Пэт Мюллер, Скотту Ричу и Саймону Арчеру за техническое обеспечение данной статьи. Я также хотел бы поблагодарить Джеймса Говернера и Стива О'Грейди, сотрудников аналитической фирмы Redmonk, побудивших меня заняться изучением Web-сервисов на основе стиля REST.

Ресурсы

Научиться

Получить продукты и технологии

  • Инструментальный комплект Dojo: Инструментальный комплект Dojo является базовым средством разработки Ajax с открытым программным кодом, которое обеспечивает абстрактные структуры программирования высокого уровня и нормализует несовместимость браузеров.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Web-архитектура, Технология Java, SOA и web-сервисы
ArticleID=176551
ArticleTitle=Ajax и REST, Часть 1
publish-date=10022006