LINUX.ORG.RU

Сайт+Rest API


1

2

Как написать сайт, который одновременно является набором REST ресурсов, которые можно обрабатывать как Rest API. Тоесть я вот беру сферически в вакууме делают Rest Api доступное через веб. С ним допустим уже может работать ПО, выполнять навигацию и все такое. А потом я поверх просто добавляю UI.

Пока приходят не совсем практичные мысли в голову.

1. Pure Ajax with hash rewriting

2. XML+XSLT

Кто-то еще что-то слышал?

★★★★☆

Backbone.js в точности то, что тебе нужно. Ну или Ember.js, или Sproutcore (тут на вкус).

Вот, например, сделал сегодня на Ember.js с бэкэндом на Yii: http://resurtm.kz/yii-backbone-tasks/

Контроллер прост как три рубля: https://github.com/resurtm/yii-backbone-tasks/blob/master/protected/controlle... (обычный CRUD, толстый клиент, общается сервер и клиент через JSON).

resurtm ★★★ ()
Ответ на: комментарий от resurtm

1. Pure Ajax with hash rewriting

Это оно. А пользователи то не привыкли что у них страница не сразу одним махом грузится, а потом начинает части подгружать и еще spinner-ом троллит. Меня Github этим убивает. А прикинь весь вебсайт такой?

vertexua ★★★★☆ ()
Ответ на: комментарий от vertexua

Это оно.

Не совсем оно. Якори — это лишь айсберг. Backbone.js привносит MV* подобную структуру (смесь MVP и MVC) на клиент и получается всё очень и очень красиво и структурировано, без спагетти-кода, который возникает, когда создаёшь приложения с очень толстым клиентом на pure low level jQuery. Разница огромная. :)

А пользователи то не привыкли что у них страница не сразу одним махом грузится, а потом начинает части подгружать и еще spinner-ом троллит. Меня Github этим убивает. А прикинь весь вебсайт такой?

Да, это недостаток. Хотя, к примеру, в GMail или в Twitter меня это абсолютно не напрягает.

resurtm ★★★ ()
Ответ на: комментарий от resurtm

Уточню ещё чуточку: это я к тому, что под понятием «pure Ajax with hash rewriting» может скрываться как абсолютно неприемлемое ни при каких условиях говно, так и конфетка первого класса (Backbone.js, Sproutcore приложения).

resurtm ★★★ ()
Ответ на: комментарий от vertexua

На сайте Backbone.js есть список real world приложений: http://backbonejs.org/#examples
Список внушительный, потестить самому и ощутить на вкус найдётся что. :)

resurtm ★★★ ()

А в чём проблема? `rails generate scaffold ...` как раз так делает. К примеру такие URI как /users, /users.json, /users.xml.

tyler19 ()
Ответ на: комментарий от tyler19

А в чём проблема? `rails generate scaffold ...` как раз так делает. К примеру такие URI как /users, /users.json, /users.xml.

Проблема в том, что ты, как backend разработчик не понимаешь, чего именно он хочет. А спрашивает он про способы, как писать правильно client side консьюмер сгенерированного серверного CRUD и какие хорошие методики для этого есть, а не то, как использовать генераторы из server side фреймворков.

resurtm ★★★ ()
Ответ на: комментарий от vertexua

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

trashymichael ★★★ ()
Ответ на: комментарий от trashymichael

далее отрендерить шаблон или вернуть данные в жсон, почему не так?

сейчас смотрю на restlet, достаточно интерестно

vertexua ★★★★☆ ()
Ответ на: комментарий от resurtm

Spoutcore не понравился, как-то слишком кардинально. )

Долго выбирал между Ember.js и Backbone.js остановился на бэкбоне. С документацией получше, не пытается быть рельсами на клиента и простой как три копейки. :)

Reaper ★★ ()

у меня на текущем проекте так и сделано. От джавы только REST API, весь UI строится исключительно Ext JS

JFreeM ★★★☆ ()
Ответ на: комментарий от vertexua

хы, не знал, оказывается наш заказчик платит за него.

JFreeM ★★★☆ ()
Ответ на: комментарий от vertexua

На работе у меня тоже ExtJS (точнее ExtGWT), но мне не нужен app, в большей мере информационный сайт. Но я просто ищу как его сделать поинтереснее

vertexua ★★★★☆ ()

XSLT или любой другой подобный шаблонизатор, как сервер-сайд, так и клиент-сайд. Другое дело, что сайт, сделанный как тупо морда к ресурсам, будет ужасен для опльзователя - нужна еще одна прослойка кода между ресурсом и вью. Можешь глянуть на то, что мы делали в hh: https://github.com/hhru/frontik

Вот пример применения технологии: https://github.com/AndrewSumin/hephaestus

dizza ★★★★★ ()
Ответ на: комментарий от Reaper

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

trashymichael ★★★ ()
Ответ на: комментарий от vertexua

На сервере и там и там. Хотя основная заморочка фронтика в асинхроности. Все это ты можешь написать сам безо всяких фронтиков

dizza ★★★★★ ()

JS клиент в браузере ничем не отличается от других клиентов, тогда проблем не вижу.

А если нужен REST и обычный HTTP доступ с броузера, тогда должно быть две точки доступа, возможно с разными путями, где один с префиксом, например /posts/1 __rest__/posts/1

bismi ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.