var extraParams = {
timestamp: +new Date()
}
if (X1<X2<X3<X4<X5<X6<X7<X8<X9<X10<X11<X12<X13<X14<X15<X16)
I've long been interested in the concept of A/B testing (Also called split testing). It's a simple concept that should sit will with most mathematically-inclined types: You have a baseline interface in which you adjust a single variable, at random, for each user that visits your application. After a given amount of time you should be able to see if certain variables affect how your users behave (either negatively or positively).
A product was recently released called SnapAds which allows its users (advertisers) to permute different variations of an ad and display different versions to users, based upon how well they perform over time.
But that's not what I was interested in, specifically (even though it is a cool idea). The team that created this also created another product a while back that never saw a full release: Genetify. Genetify provides developers with a JavaScript library for doing any number of A/B tests on a site (tweaking CSS, JavaScript, or HTML elements) all trained over time using a Genetic algorithm backend.
This means that no matter how many different A/B tests you have on a page the genetic algorithm will adapt to the input (users visiting the page and hopefully achieving some pre-defined goal) and slowly show a more-optimal page layout to the user.
Genetify provides a demo on their site showing the basics of how it works along with a simple text tutorial.
To get started with Genetify you will need to include the library in the head of your page along with a couple CSS rules.
And then before the closing body tag on your site include the following:
Here are some examples of different ways in which a page layout can be changed using Genetify.
HTML Elements / CSS Classes
The easiest technique is one which allows you to simply toggle HTML using some inline CSS classes.
The first class specified ends up becoming the name of one of the "genes" which is used to train the genetic algorithm. Thus if the user completes a specified goal while the "anotherway" element is toggled then the algorithm is trained to recognize that showing the "anotherway" element might be more desirable and will show it more over time.
A goal can be recorded by specifying a goal name and a weight for completing the goal. You'll need to call a JavaScript method that records the completion of a goal wherever in your code you think the goal was completed (such as the user signing up for something).
The next-most-common technique will likely be that of toggling CSS rules. Multiple rules are defined using a similar name but with the addition of a simple alphabetical name on the end which is used for categorization.
Note that you can have any number of rules - you aren't limited to the traditional "A/B" style of testing where there's only two options - specifying any number of rules will continue to yield results.
Finally Genetify provides the developer with the ability to toggle JavaScript variables.
I'm less excited about this particular technique - it's kind of clumsy to clutter the global namespace with variables and to expect a changed output. I think a better technique would be to toggle a property value within the genetify object and check how that's changed, instead.
Perhaps the biggest question that surrounds Genetify, right now, is over its longevity and openness. It seems like the project has taken the backburner in favor of the team's other project, SnapAds (and understandably so - since that has an obvious revenue stream). Although a recent comment by its creator, over at Hacker News has fueled speculation: He's looking for interest in the possibility of open sourcing the codebase for anyone to use.
Right now Genetify is two components:
I'm already quite excited about this utility. I think it shows a lot of promise for developers who want to roll their own A/B testing solutions. I hope the team comes through and releases an Open Source solution that developers can really start to hack on it.
Shared by arty
используйте display: table-row и т.п. для браузеров, а для ие всё равно придётся подсовывать отдельные стили
Today, a talented web designer must be a modern-day MacGyver—that 80s TV action hero who could turn a rubber band and three tin cans into a serviceable aircraft. Turning the average site design mockup into a living, breathing slice of HTML and CSS is a comparably delicate miracle, which must be accomplished using whatever makeshift tools happen to be lying around in current browsers.
That’s exactly why so many professional designers still choose to use HTML tables for layout. How can we expect beginners to adopt CSS for layout when it takes someone with the resourcefulness (and snappy dress sense) of MacGyver to fully understand the techniques involved?
Thanks to the imminent release of Internet Explorer 8, CSS layout is about to become something anyone can learn to do—no chewing gum or makeshift explosives required.
HTML tables produce the grid-based layouts we want to achieve with relative ease, but the price is that users with screen readers and other technologies that rely on semantic markup have a hard time making sense of the page.
As standards-conscious designers, we have convinced ourselves that the benefits of semantically meaningful markup are worth the added hassle of using CSS for layout. Not everyone shares this conviction. Whenever I write about some new CSS layout technique, at least half the feedback I get boils down to “You’re kidding yourself if you think designers will use that instead of HTML tables.”
The reason this is such a contentious issue is that tables correspond so well to the way designers tend to think of pages: a semi-flexible grid that defines rectangular areas that make up the page. If you want three columns in a row, you just put three table cell tags inside a table row tag:
<table> <tbody> <tr> <td>column 1</td> <td>column 2</td> <td>column 3</td> </tr> </tbody>
</table>The premise of using CSS for layout is sound: replace the HTML tables with semantically meaningful markup, plus semantically invisible divs where needed:
<div id="container"> <div> <div id="menu">column 1</div> <div id="content">column 2</div> <div id="sidebar">column 3</div> </div>
</div>The problem is the CSS code required to lay out this new markup. CSS was not initially designed to support blocks arranged horizontally across the page; consequently, we have had to get creative with the tools at our disposal. Current best practice requires the designer to master subtle interactions like overlapping floats, negative margins, and other black magic to achieve a simple multi-column layout. You don’t so much describe the layout you want as gradually build up a combination of positioning constraints that almost miraculously result in the layout you’re after. You couldn’t come up with a more convoluted way of expressing page layout if you tried!
If CSS layout code were as easy to write as HTML tables, making the leap would be a no-brainer; designers would flock to CSS willingly. Instead, we must drag them kicking and screaming, because the tools that CSS provides are not suited to the layout tasks we want to accomplish.
What if CSS provided a set of tools that applied to practical layout tasks as obviously as HTML tables do?
CSS actually includes a feature that works just like HTML tables: CSS tables. Using the CSS display property, you can instruct the browser to format any HTML element as if it were a table. For visual display purposes the element behaves like a table, but the element retains its non-table semantics for screen readers and other tools that look at the HTML markup.
In short, CSS tables let you perform table-based layout without misusing HTML tables!
The CSS to lay out our collection of divs above as a row of three table cells is very straightforward:
#container { display: table; border-collapse: collapse; table-layout: fixed;
}
#container > div { display: table-row;
}
#container > div > div { display: table-cell;
}We can then set the widths of each of our columns, again with very straightforward code:
#menu { width: 200px;
}
#content { width: 66%;
}
#sidebar { width: 33%;
}From this foundation, applying borders and backgrounds to these columns is trivial. Check out this sample page, and the screenshot below for a fully-rendered example. Now this is the kind of page layout code that designers can embrace with confidence!
Compared with HTML tables, CSS tables have only one notable weakness: CSS does not allow for table cells to span rows or columns the way they can in HTML tables (with the rowspan and colspan attributes). As it turns out, however, this is a relatively uncommon requirement for page layouts; and in the few cases where spans are required, there are ways to fake them with CSS tables.
So, why isn’t everyone already using CSS tables for page layout? In an all-too-familiar twist, we have Internet Explorer to blame. CSS tables are supported in every major browser except Internet Explorer. However, the good news is that Internet Explorer 8 will have full support for CSS tables upon its release, setting the stage for CSS tables to become the preferred tool for page layout on the web!
The question you must ask yourself is, “When can I start making the switch?” The answer may depend on the type of site you work on.
If you work professionally on a mainstream website, chances are you will be expected to keep your site working on Internet Explorer 6 and 7 for some time to come. Since neither of these browsers support CSS tables, it may seem on the surface that you’re out of luck. In fact, CSS tables may still make your job easier.
Because CSS tables are so much easier to work with than previous CSS layout techniques, you may find it worthwhile to implement your design first using CSS tables, and then using older CSS techniques for IE6 and IE7. You can use conditional comments to insert your IE6/IE7 style sheet, while all other browsers will only get the table-based layout. This approach does mean you have to implement your layout twice, but it saves you the considerable headache of getting the older techniques from working both in Internet Explorer and in other browsers.
While you’re at it, you may find opportunities to simplify the layout slightly in the IE6/IE7 version of the site, and save yourself a lot of work. Something like not insisting that a column’s background color extend all the way to the bottom of the page can radically simplify the code, for example.
If you work on a site with a more technical audience, or owned by a more progressively-minded organization, you might have even more wiggle room. In this case, you should explore the possibility of providing a simplified page layout for IE6 and IE7. The sample page included with this article is written this way. In the screenshots below, you can see the page displayed in IE8 (beta 2) and IE6.
If you find yourself having to defend this approach to a client, tell them how much of your time (and their money) will be saved by simplifying the layout a little in outdated browsers.
Even if you can’t justify working with CSS tables in your day job just yet, it’s worth finding excuses to use them where you can. When Internet Explorer 5.5 made CSS layout across browsers possible for the first time, Jeffrey Zeldman wrote To Hell With Bad Browsers, leading the call for designers to adopt CSS layout:
“For years, the goal of a Web that was accessible to all looked more like an opium dream than reality. Then, in the year 2000, Microsoft, Netscape, and Opera began delivering the goods. At last we can repay their efforts by using these standards in our sites. We encourage others to do the same.”
The response to this call to action was gradual, but effective. Initially, web designers began experimenting with CSS layout on their personal sites, before testing the waters with some of their riskier side projects. Major mainstream sites like ESPN began making the switch only a couple of years later.
With Internet Explorer 8 on the verge of release, the stage is set for another wave of change to sweep the Web, however gradually. Now is the time to ensure you’re on the leading edge, not paddling to catch up!
Perhaps the most important benefit of CSS tables is that it finally makes page layout with CSS easy to learn. Finally, we can justifiably expect anyone designing a web site today to do it the right way, with a proper separation of content (HTML) and presentation (CSS).
In my just-released book, Everything You Know About CSS Is Wrong (available from Amazon: Everything You Know About CSS is Wrong!
« |
Мнение Владимира Вагина: Интернет и ТВ — это два абсолютно разных бизнес-стиля. Ребята, которые это создавали, ориентировались на нормы интернета. Если в RuTube приходит профессиональный телеконтент, то тут начинают работать совершенно другие принципы и нормы прибыли. Этим должны заниматься телевизионщики. У ТНТ уже есть богатая библиотека телепередач и кино, нужна лишь площадка, где они адаптируют его к интернету. Собственно, сами интернетчики тут не нужны. Зачем «Газпром-медиа» RuTube и что он будет с ним делать, Частный корреспондент |
» |
А теперь мы посмотрим, как, разогнав команду успешного стартапа, наши телевизионщики будут строить российский Hulu.com поверх контента из медиатек ТНТ и НТВ. Интересно, как пойдет — с точки зрения телевидения оба канала успешны, оба как бы обладают неплохими сайтами, но стать какими-то заметными онлайн-источниками контента у них не вышло.
Ждать, что «вдруг из подворотни выйдет великан» не приходится, а новой команде придётся определиться с тем, как решать главные вопросы — реклама, пользователи, обратная связь и интеграция всего этого в стройную и непротиворечивую систему. Пока, если судить как раз по Hulu, ТВ приходится очень непросто с онлайн-рекламой за пределами видео (т.е. не в виде рекламных роликов), а увидеть вменяемые сообщества на медийных сайтах нам ещё только предстоит. Достаточно сравнить официальную ленту канала ТНТ на Рутьюбе с его почти одиннадцатью тысячами роликов, и всего лишь одного сериала «Фринж», которому от рода 8 серий, а в форуме 203 топика и 140 рецензий. (К вопросу о блеске UGC: у верхней рецензии там славный заголовок «One of the best shoes....»)
C другой стороны, понятно, что прибыль можно получить, даже если использовать Рутьюб как промо-площадку для всевозможной продукции, от новых фильмов на ТВ и дивидисков, идущих в продажу, до шарфов и носков с символикой сериалов. Или продавать мобильные версии роликов Камеди Клаб по два доллара — уже монетизация. Правда, уровень немного другой. Ларёчный.
* * *
Мне это крайне любопытно ещё и потому, что Афиша, запуская свои тв и видеопроекты, очевидно, метила в ту же нишу — но то ли ресурсов, то ли воли на полноценную реализацию телепортала не хватило, и только-только сейчас начинают появляться отголоски этого давно задуманного «интеграционного» движения, когда каждый объект становится самостоятельным сайтом, с полным досье, архивами, обсуждениями, рецензиями и клипами, независимо от того, концерт это, фильм, сериал или клуб. Поэтому, помня эти долгосрочные планы Афиши, я и наблюдаю за тем, как развивается тема поддержки телевидения в России.
Shared by artySo! I have all these cool things I want to write about, but I broke my thumbnail. Can you tell that's a long story?
why JavaScript is a better language than Emacs Lisp
вместо самого кода писатели на хабре начали вставлять в тексты картинки с этим самым кодом
интересно, что нам это говорит о сайте? : )
иронично, кстати, что и программистов хабра, и писателей подводит тяга к красоте
громкий заголовок, ага? Но я написал его с полной серьёзностью, и уверен в своих словах. Конечно, сейчас их придётся обосновывать.
я считаю, что одно из самых часто выполняемых в интернете действий — это переход по ссылке на следующую в списке страницу. Без страниц никуда. Раньше «пейджеры» почти все были строго цифровыми, потом начали распространяться дополнительные надписи «следующая» и «предыдущая», и стало удобнее. Но можно сделать ещё лучше!
многие страницы не умещаются на один экран, и их приходится прокручивать. Мне было бы жалко потерять веру в человечество, поэтому об использовании для этой цели скроллбара даже не буду говорить. Остаётся не так много способов: колесо мыши, «pan» мышью (обычно после клика средней кнопкой), стрелки, кнопки pgup/pgdown и пробел.
проматывать страницы пробелом очень удобно: он всегда под большим пальцем, и работает аналогично переворачиванию бумажной страницы: начинаешь читать новую как раз там, где оставил предыдущую. (Есть небольшой минус в крайних случах, но эту проблему решают.)
обычно, если читаешь разбитый на страницы текст, хочешь перейти на следующую страницу как раз тогда, когда закончил читать уже открытую. Поэтому в большинстве случаев в конце страницы ставят «пейджер». Но всё равно нужную ссылку нужно найти глазами и мышкой, и это требует времени.
наверное, пользователи оперы уже давно догадались, к чему я клоню. Да, именно в опере пробел доработан очень удобной фичей: переходом на следующую страницу при необходимости. То есть, если страница уже промотана до конца, и вы нажимаете пробел ещё раз, опера открывает следующую страницу. Но как она её находит?
для этого уже очень давно подходящей ссылке можно установить атрибут rel="next". Именно его я и считаю самым полезным микроформатом. Знатоки, вероятно, возразят, «какой же это микроформат, он есть даже в спеке html4», и будут правы. Тем не менее, чёткого определения микроформата нет, а некоторые из существующих, типа rel-tag и rel-directory очень близки герою этой заметки. Кроме того, поддержка в браузерах у него как раз на уровне микроформатов ; )
итак, берём ссылку на следующую страницу, задаём ей атрибут rel="next", и всё шоколадно. Как вариант — делаем то же самое с элементом link в head. Это работает, но есть один ньюанс: мы все знаем, сколько веб-авторов читают спецификации и следуют им. Поэтому опера не ограничивается поиском таких элементов, но ещё пытается найти ссылки со словами next/следующий/forward/→/->/=> и так далее. Получается не всегда, но довольно часто, и то хлеб.
ну а что же другие браузеры и, не побоюсь этого слова, обозреватели? В сафари я такого пока что не видел, но буду рад, если меня поправят. «Самый расширяемый браузер» тоже отчасти не у дел, и вот почему. Да, к нему есть пара плагинов NextPlease и Link Widgets. Последний притворяется Navigation Bar из оперы, показывая кнопки-ссылки next/previous/first/last/home/index. Первый решает только задачу обнаружить ссылки на предыдущую и следующую страницы, но решает хорошо, за одним исключением — не поддерживает «умный пробел».
впрочем, проблемы не страшны, если в наших шаловливых ручках user javascript! Установите простой скриптик «Smart spacebar → next page», и протестируйте его хотя бы в поиске гугла. Думаю, вам понравится : ) А user feedback может сподвигнуть меня и на более продвинутый поиск следующей страницы. Хотя, по-хорошему, поддержку этого нужно встраивать в NextPlease.
жалко, что такую вещь не получится сделать в Thunderbird, потому что читать письма пробелом в опере тоже очень удобно — заканчиваешь одно и переходишь к следующему. Впрочем, если кто-то прикрутил жирную обезьяну и к почтовику, честь ему и хвала.
и да, не зажимайте пробел, чтобы быстро промотать к концу страницы ; )
Освоение регионов, альтернативная энергетика, собственные дата-центры IT-компаний, специализация по инструментам и другие возможные тренды развития отечественного хостинга.
в связи с недавней сменой работы я в очередной раз начал искать подходящий редактор яваскрипта. Нельзя сказать, что в этом деле я преуспел, но надежды пока не теряю. Хотя, судя по тому, что решил всё-таки глянуть emacs, жить надежде осталось недолго : )
The following NEW packages will be installed:
emacsen-common libcompfaceg1 xemacs21 xemacs21-basesupport xemacs21-bin xemacs21-mule xemacs21-mulesupport xemacs21-support
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 33.1MB of archives.
After this operation, 107MB of additional disk space will be used.
для описания этого у меня нет цензурных слов. СТО СЕМЬ МЕГАБАЙТ!!! Да эклипс меньше весит, с его-то репутацией. И эти люди запрещают ковырять ругают bloatware…
но ладно, скрепя сердце, поставил этого монстра. Запустил. И понял, почему оно столько весит. Для машины времени нужна большая программа. А xemacs перенёс меня точнёхонько в 1973 год, по крайней мере, интерфейс его выглядит точно как у Xerox Alto — первого компьютера с гуём. Ребят, прошло уже тридцать пять лет, а вы так себя не уважаете. Вы ещё клавиатуру от пишмашинки к компу подключите, чтобы «классические ощущения» сохранить.
эх, разочарован : (
если что, я не знаю, сколько весит vim, но имхо его интерфейс тоже сосёт. Даже несмотря на то, что выходить из него я могу не только резетом.
update: просто emacs получше выглядит. Немного. Но скроллбар слева? А как насчёт сглаженных шрифтов?
интересно, отсутствие флеша на ифоне уже привило каким-нибудь веб-разработчикам нелюбовь к флешу? : )
Мало кто знает, но они действительно существуют.
Проблема полупрозрачных картинок медленно умирает вместе с IE5-6, но, тем не менее будет актуальна для популярных сайтов еще несколько лет. Вдобавок, дальше станет понятно, почему процентная прозрачность для PNG-8 будет важна и без ИЕ.
Казалось бы, «Ну и что? Все равно альфа-каналы в ИЕ работать не будут, толку?».
Однако, толк в том, что полупрозрачные пикселы в PNG-8 при просмотре в ИЕ будут показаны полностью прозрачными. Все остальные броузеры честно отобразят их полупрозрачными. Более того, не будет никакого уродливого серо-белого фона, который видно при просмотре PNG-24 картинок в Интернет Эксплорере.
То есть: все пикселы с прозрачностью от 0 до 99% будут отображены IE как полностью прозрачные.
Это странно и дико, но сделать это в Photoshop нельзя. (возможно в CS4…?)
Зато такую картинку можно сохранить в Fireworks! Там это делается очень просто, при экспорте выбираем опции:
Трудно ошибиться, нужно выбрать формат PNG-8 и тип прозрачности «Alpha Transparency». Видно также, что в палитре все цвета имеют прозрачность кроме одного (крайнего справа)
Почему этого нет в Photoshop, загадка.
Также существуют утилиты, превращающие PNG-24 в PNG-8. Естественно, при этом качество страдает, но часто с этим можно жить.
Для примера, я сохранил одну и ту же картинку в трех форматах: PNG-24, PNG-8 обычный, и PNG-8 с альфа-каналами (из Fireworks). Все три поместил на узорчатый фон. Вот что вышло:
PNG картинки в Firefox
Ничего особо интересного, кроме размеров картинок. Обратите внимание на вес PNG-24 и PNG-8 файлов, при почти идентичном отображении.
А теперь, в ИЕ:
PNG картинки в IE. Хорошо видно «серо-белое уродство» упомянутое ранее
Вуаля! То, что называется «graceful degradation»!
Сами смотрите, если не верите. ;)
За фон благодарен.
Вряд ли это знание поможет вам познакомиться с девушкой вашей мечты, или начать наконец делать зарядку по утрам. Но, некоторая польза все же есть.
Во-первых, это экономит трафик. Во-вторых, в большинстве случаев отлично деградирует в ИЕ. То есть, можно применять для всяких некритичных украшательских штучек. В IE будет отображен обычный PNG-8 (а ля GIF), а для всех остальных полупрозрачная красота.
Разумеется, в некоторых случаях картинки будут казаться выщербленными в IE (резкие края), но никто и не говорит, что этот способ панацея.
Эта техника, кстати, в некоторых случаях могла бы чуть-чуть упростить вот этот супер-универсальный трюк Виталия. Другие заметки по теме:
Уверен, кто-то уже это использовал. Знание это совсем не новое, но малоизвестное почему-то. Потому, был бы рад если бы вы поделились опытом по теме.
Shared by artyРазрабатывая проект наткнулся на странный глюк в IE. Некоторые стили просто не применялись к странице. Т.к. проект большой и стилей много, на этапе разработки CSS был разбит на много файлов для каждого логически отдельного блока. Выясняя причину я, опытным путём, пришёл к тому, что IE подгружает максимально 31 внешний CSS файл через. Остальные файлы просто игнорируются.
чёрт, ещё куча неожиданных ограничений в комментах
мой способ браузинга и раньше был не очень-то стандартным, но в последнее время я достиг прямо-таки выдающихся вершин необычности. Судите сами:
удивительно, что интернет при всём этом работает : ) И работает очень даже неплохо. Конечно, некоторые убожества типа фконтакте отказываются служить, но тем хуже для них — ухожу без сомнений. Единственная уступка, на которую я иду для некоторых ценных сайтов типа гугла и дёрти — включаю им яваскрипт.
а теперь о плюсах, потому что минусы и так ясны. Плюса два, и они крупные. Первый: теперь интернет поставляет мне не дизайнерские изыски, а нужную информацию, причем сразу в удобном для употребления виде. Второй: он делает это быстро. Никаких счётчиков, никаких тормозов гугловой статистики, практически никакой рекламы (спасибо отключению ифреймов). Всё супер : )
впрочем, проявился один неожиданный недостаток: отключение яваскрипта лишило меня юзерскриптов. Но ничего: это были только приятные мелочи, а у оперы всё равно скоро будут плагины.
Этот пост лежит у меня в черновиках уже очень давно. Все боюсь флейм нездоровый породить :-). Но все же тема мне представляется важной, и в рамках борьбы со старинными хвостами я его таки вот написал. Заранее извиняюсь, если это “и так все знают”, тема действительно уже не нова.
Также должен оговориться, что я не буду подробно описывать, что такое REST сам по себе, потому что это отдельный глубокий и труднопередаваемый вопрос. Вместо этого сошлюсь например на аналогичную этой статью классика темы Джо Грегорио “REST and WS-*“, там он про REST пишет более подробно. А эта статья — о том, почему REST и WS-* нельзя сравнивать, почему их все-таки сравнивают, и почему первое лучше второго. Да, никакой объективности от меня тут ждать не надо :-).
Речь пойдет о построении веб-сервисов: сайтов, открытых в публичный веб и явно предполагающих машинную обработку. Определение слегка общее, поэтому стоит подчеркнуть, что к ним не относится:
Representational State Transfer — это набор общих принципов построения веб-сервисов с определенными приоритетами: масштабируемость, независимость от платформы, расширяемость. Эти принципы были сформулированы Роем Филдингом, одним из разработчиков HTTP 1.1, в своей диссертации, посвященной как раз этим вопросам.
Поскольку REST — это архитектура (или точнее “архитектурный стиль”), то в природе, по идее, не может существовать таких вещей, как “протокол REST” или “библиотека REST”. Хотя библиотеки и есть, но они, на самом деле, реализуют не шарообразный REST а обычно что-то более конкретное с использованием REST-принципов. Также и с протоколом: обычно все имеют в виду самый распространенный протокол общего назначения, реализованный на REST-принципах — HTTP 1.1. Однако эти принципы можно применять и с другими протоколами, например с той же CORBA. А также эти принципы можно применять не целиком: ваша системы не обязана быть абсолютно чисто REST’овой, а может быть таковой местами.
Основной смысл REST’а, таким образом, в том, что он описывает то, в каких терминах надо думать, чтобы делать клиент-серверные системы, работающие в вебе, и не нарушающие общей экосистемы.
WS-* — это обобщенное название набора спецификаций, большая часть которых начинается с букв “WS” (хотя самая базовая — SOAP — с них не начинается). “WS” означает буквально “Web Services” и, надо сказать, является источником заблуждения, что веб-сервисы — это то, что построено именно на этом стеке.
Одним из приоритетов подхода, заложенного в WS-спецификации, является автоматизация публикации и доступа к объектам программных систем в виде интерфейса, доступного через HTTP. В идеале программист должен работать с чем-то на другом веб-сервисе так же прозрачно, как и с объектами в памяти его собственной программы. Пересылку данных, проверку типов и прочий сервис обеспечивает WS-*. Для достижения этого спецификации не абстрактны, а наоборот, очень конкретны и детальны, и, что важно, подразумевают не прямое программирование по описанным протоколам, а использование инструментов среды программирования, генерирующих необходимую обвязку.
Стоит добавить, что главными продвигателями WS-* являются Microsoft и IBM.
Из кратких описаний должно быть понятно, что впрямую сравнивать эти вещи нельзя. Во-первых, они просто разного уровня: одно — архитектурные принципы, другое — набор протоколов с реализациями. Во-вторых, они не взаимоисключающи: вполне можно делать системы на WS-* протоколах с использованием REST-принципов. У меня в голове как-то родилась аналогия, что сравнение REST и WS-* — это примерно то же, что сравнение функционального программирования и Visual Studio.
Но тем не менее… Тем не менее, сравнение все таки напрашивается, пусть даже и на эмоциональном уровне. И оно таки имеет смысл!
REST и WS-* являются ключевыми понятиями для совершенно разных подходов к созданию веб-сервисов. И неважно, что они сами находятся на разных уровнях, важно, что они подразумевают очень конкретный инструментальный стек, в рамках которого работают:
| REST | WS-* | |
|---|---|---|
| Архитектура | REST | RPC-стиль |
| Транспортный протокол | HTTP | HTTP |
| Протокол описания сообщений | HTTP | SOAP |
| Сервисные протоколы (авторизация, кеширование, проксирование) | HTTP | WS-* |
| Описание форматов | MIME-типы | XML Schema |
| Глобальная система идентификации | URI/URL | Отсутствует |
| Описание интерфейсов сервисов | Отсутствует | WSDL |
| Инструментарий | Низкоуровневый (парсинг XML, JSON и др.) | Высокоуровневый (абстракция доступа к удаленным объектам) |
Все это нуждается в разъяснениях.
Архитектура REST диктует, что
WS-сервис никакой конкретной архитектурой не обладает. Снаружи — это “черный ящик”, у которого есть набор специфичных методов, которые можно вызывать. Что у него внутри, известно только его разработчику. Также исключительно на совести разработчика находится масштабируемость сервиса, поскольку WS-стек тут никаких решений не подсказывает. Чаще всего поэтому WS-системы предоставляют RPC-подобный интерфейс, потому что это то, что получается само собой, если над ним особенно не задумываться.
Оба стека используют HTTP, но сильно по-разному.
HTTP создавался как каноническая реализация REST-принципов, и цели этой достиг. Теперь для большинства REST-ориентированных система HTTP — это все: хлеб, масло и колбаса сверху. Или более формально — и транспорт, и метаданные и сервис. А именно:
WS-* же использует HTTP фактически только как транспорт для передачи SOAP-вызовов. И, собственно говоря, заявляется, что HTTP для WS-* — только один из транспортов, и можно использовать другие. Для всего остального в стеке придуманы свои аналоги. В частности, SOAP-сообщение состоит из заголовков и тела, и именно эти заголовки, а не HTTPшные, имеют значение. Куча остальных фич реализована различными WS-протоколами, про которые я подробно распространяться не буду за незнанием, а лучше еще раз сошлюсь на источник.
Одно из основных положений REST’а — использование для описание форматов данных MIME-типов. Лучше всего, если сервис использует уже известный и описанный MIME-тип. Например, если вы выдаете какие-то календарные события, то желательно их выдавать в формате iCal с заголовком Content-type: text/calendar. Еще одна возможность — использование XHTML с микроформатами, потому что это тоже описанные данные, и под них есть парсеры. И если только совсем не получается найти подходящий MIME-тип, тогда только можно придумать свой собственный XML и очень тщательно его описать. Еще желательно его в IANA зарегистрировать, но это уж как получится :-).
WS-стек не имеет описания формата передаваемых данных в целом. Точнее, форматом является некий абстрактный SOAP-конверт, но он не означает ничего конкретного — это просто транспорт. Вместо этого описываются типы параметров, которые передаются внутри этого конверта. Строки, числа, даты. При передаче они сами по себе не связаны никакой семантикой, и что с ними делать, определяется тем, какой метод какого объекта вызывается с этими параметрами.
Это различие, в сочетании с универсальным интерфейсом, делает REST-сообщения самоописывающимися, а SOAP-сообщения — нет. Даже если оно содержит только известные типы данных, смысл его разный для каждого конкретного вызова каждого конкретного объекта.
В REST есть понятие глобального идентификатора, которым по сути является хорошо всем известный URL (точнее, URI, но разница несущественна). Прелесть его наличия в том, что он создает единый интерфейс ссылок на ресурсы между разными сервисами, которые друг про друга ничего не знают. Например, REST-сервис, работающий с картинками, может принимать к себе как непосредственно представления картинок с MIME-типом image/something, так и URL’ы картинок, которые могут быть расположены где угодно.
Еще один важный плюс — это то, что одними только URL’ам сервис может описывать свой собственный протокол. URL’ы, встречающиеся в выдаваемых представлениях ресурсов, как в телах, так и в заголовках — это новые ресурсы, в которые клиент может стучаться для того, чтобы делать с сервисом что-то еще. И поскольку формирование URL’ов является обязанностью сервиса, это позволяет ему свободно менять схему своих URL’ов, не боясь сломать клиентов, которые всегда работают только с готовыми URL’ами, а не составляют их по каким-то правилам.
В WS-стеке глобальных идентификаторов нет, так как нет самого понятия разных ресурсов. Все операции с сервисом делаются только через одну точку по уникальным для этого сервиса правилам.
Для описание интерфейсов WS-сервисов есть развитый язык WSDL, который подробно описывает, какие у сервиса есть объекты, какие у них есть методы, и какие у них есть параметры. Формат сложный, с-трудом-человекочитаемый, и рассчитан на то, что он будет генерироваться средствами IDE автоматически по реально существующим объектам системы.
В REST-сервисах никакой прямой аналог WSDL не нужен, потому что все ресурсы обладают уже заранее известным интерфейсом.
Стоит заметить, что WSDL в WS-стеке играет примерно ту же роль, что наличие URL’ов в REST-системах — описывает то, что можно делать с сервисом. Хотя очевидна разница в акценте. WSDL полезен клиенту по сути только для автоматической генерации стабов, и ничего не говорит о семантике вызовов. В то время как по наличию URL’ов в REST-ресурсах, описанных в подходящих местах, можно делать конкретные выводы о том, как их использовать.
Есть еще одна проблема с автоматической публикацией интерфейсов объектов наружу. Интерфейсы объектов внутри хорошо спроектированной системы гарантируют только корректность обращений к самим объектам, но не всегда определяет, в каком, грубо говоря, порядке их нужно вызывать по бизнес-логике. Например в неком форуме могут быть внутренние объекты “Топик” и “Статья”, и бизнес-правило, что в топике должна быть хотя бы одна статья. Простая публикация интерфейсов объектов наружу не даст гарантии, что пользователи будут создавать статью к каждому созданному топику. Поэтому для внешнего мира обычно все равно нужно создавать отдельный слой кода, который такую логику поддерживает, и без этого одна только публикация объектов бесполезна.
Инструментарий — по сути главная часть WS-стека. Его задача — создать в IDE программиста клиентского приложения удобную абстракцию для доступа к серверным объектам. Соответственно, без автоматической генерации и парсинга WSDL-описаний и SOAP-сообщений тут делать нечего. Я не возьмусь судить, насколько это все выходит удобным, но то, что выглядит это все довольно Солидным и Сложным — это точно. Есть даже точка зрения, что вся эта великая концепция была как раз и рождена для создания рынка инструментария. Большой минус у этого подхода в том, что она работает только на тех платформах, которые интересно обслуживать производителям инструментов.
Для работы с REST-системами никакого одного набора инструментов нет и быть не может. Вместо этого вам предлагается пользоваться вещами, подходящими для конкретных задач. Нужно общаться с HTTP — возьмите хорошую HTTP-библотеку, коих много. Нужна более сложная авторизация — есть библиотеки для digest-авторизации, OAuth’а и т.д. Парсинг XML, JSON и прочих форматов и подформатов — тоже в библиотеках. Каждую из таких небольших библиотек вполне может написать один человек, а не целая компания.
Все технические различия в подходах, акцентах и назначениях между REST и WS-* складываются в хорошо ощутимое различие культурное.
WS-стек — это инструмент для разработчиков, которым нравится работать в среде, которую для них создает большой солидный вендор, которому они сильно доверяют. Их не беспокоят мелочные вопросы типа “как работают вещи внутри”, им неважно, будет ли их сервис удобно программировать кому-то на странном маргинальном языке программирования. Им интересно, чтобы у каждой решаемой задачи уже был кем-то одобренный верный способ решения. А если он не решает задачу, то разработчик вроде как все равно не виноват — надо просто купить новую “более enterprise” версию решения, в которой это все точно уже сделано.
REST — явный любимец open source культуры. Для людей, которые не будут спать ночами, придумывая, как покрасивее описать интерфейс системы в виде stateless-ресурсов. Которым важно знать, что если им захочется написать сервис на Erlang’е, они смогут опубликовать ресурс в XML-виде, не дожидаясь, пока кто-то напишет SOAP и WSDL генераторы для Erlang’а. И которым в принципе не все равно, насколько незлым будет их сервис по отношению к другим жителям веба.
И вот поэтому я утверждаю, что:
WS-* — плохой способ делать веб-сервисы. Он решает ненужные проблемы, зато не решает нужных.
При написании этой статьи у меня скопилось некоторое количество ссылок по теме. Привожу их здесь в произвольном порядке:
MochiAds - Flash Game Ad Network — распределенная система показывания рекламы в играх, использующая HTTP для связи серверных компонентов на Erlang и клиента на Python.
REST, I just want it и Explaining REST to Damien Katz — реакции на статью Дамиена Каца о том, как он не понимает REST.
Learning REST — подборка ссылок Тима Брея с различными объяснениями концепций REST.
REST APIs must be hypertext-driven — недавняя нашумевшая статья Самого Филдинга о том, как многие создатели REST API не схватывают принципа ссылочности.
как такое может произойти?
[arty@arty-home:~]$ sudo apt-get install epiphany-browser
zsh: command not found: sudo apt-get install epiphany-browser