Вообще, оно так и реализовано (в chrome и mozilla, к примеру).
Проблема в том, что многие элементы отрабатывают разные сценарии по наведению указателя и по нажатию. Проще говоря, эффектом hover на ссылке мы успеем насладиться ровно до того момента, пока не произойдет переход.
Ну, теперь все, кто заглянул в статью почерпнут уйму полезной информации для себя, спасибо. Но ведь наша с вами дискуссия началась с того, что вы утверждали, что REST API не существует. Если я правильно поняла ваш последний комментарий, то вы согласны, что при соблюдении всех условий REST, программный продукт, представляющий собой программный интерфейс, может именоваться REST API?
REST никоим образом не завязан на гипертексте, мне гораздо чаще встречались реализации с данными в формате JSON.
Гипертекст, формально говоря, — это текст со ссылками на другие гипертексты (википедия).
Гипермедиа, отвечающая за «H» в HATEOAS, в свою очередь, в любом REST сервисе используется практически всегда, так как в нее входят помимо размеченного текста еще и медийные ресурсы (фото, аудио, видео)
Но статья то как раз про разработку именно в этом «архитектурном стиле», и гипертекст в нем, в большинстве своем не используется, разве что для передачи структурированных статей или описаний.
Смею считать, что программный интерфейс протокола уступает в смысловой нагрузке программному интерфейсу передачи состояний. Хотя по данным google http api действительно используется чаще нежели чем rest api.
Признаюсь, мне и в голову не приходило что кто-то может подумать, что статья про API Arduino, к примеру, да и в анонсе статьи вроде бы недвусмысленно обозначена тематика. Возможно стоит добавить RESTful API в название?
Да, документация разбита на несколько файлов, которые можно тестировать отдельно или вместе.
А по коммиту в репозиторий файлы склеиваются в один и публикуются на apiary
В общем случае, мы описываем пары Request/Response для ситуаций, где меняется JSON-схема: например, для успешного ответа и ответов с ошибками.
Фактически, использование именно сервиса Apiary (и формата apiblueprint, как следствие) обусловлено необходимостью иметь актуальную документацию по API с минимальной тратой ресурсов на ее поддержание.
С учетом того, что код покрыт модульными тестами (прекондишены мы тестируем именно там), достаточно видеть, что API возвращает что-то более-менее похожее на правду.
Статья про Keep It Simple (Silly,Sweetheart,etc), как верно подметили rumkin и Source в комментариях, и вы не первый уже предлагаете использовать что-то, от чего понадобится минимум функций просто потому что оно уже есть / знакомо вам.
Единственное, что мне нужно было — это преобразовать markdown разметку в html. Showdown это и делает, это и ничего больше.
1. Плагин, описанный в статье позволяет сразу сохранять в этом формате из Word, а Github клиент в два клика изменения публикует. Касательно редактуры конфига — в данном случае автор сам справился, но никто не мешает написать UI, если такая необходимость возникнет
2. Загрузятся две. Предыдущая и запрошенная.
3. На своем сервере потребовалось бы поднять свой git, к нему делать отрисовку логов, давать возможность watch. По поводу скорости: сайт с большой картинкой на первом экране и svg на странице (суммарно 500кб) + шрифт, пару скриптов в т.ч. с шарилками. Сервер тут вообще не причем — он быстро все отдает.
4. А если вы в книгу человек закладку вложить забудет? Пока сложно сказать, есть ли нужда в карте. Технически — реализуемо и быстро (все есть в конфиге — нужно только вывести по порядку).
5. Да. В данном случае нет задачи поддержать пользователей IE, Edge и старых версий — целевая аудитория продукта не та, да и я лично против поддержки кривого по.
Writage справляется неплохо, если у того, кто им пользуется есть представление о markdown. В моем случае пришлось объяснять, что специальные символы (например "-" с последующим пробелом в начале строки) лучше не использовать. В остальном — результат не отличается.
А что вы считаете уровнем? Просто/сложно? Я склонна ко мнению, что это оценка субъективна. Задача про крестики-нолики скорее на логику нежели чем на знание JavaScript, к примеру. Джуниору, возможно, только она и нужна, опыта он же в конце концов и идет набираться. А вышеописанную задачу, которая по сути сводится к проектированию архитектуры приложения, нежели к самому коду, он будет решать на
таблица в бд + ckeditor. И править проще, и не надо это вот аяксовые loadPage.
(см. ниже в комментариях)
Ну и так, чтобы закрыть тему: я не ищу работу ни джуниором, ни кем ли бы то ни было и не претендую ни на ваши места, ни на ваши заслуги. Можете откинуться на спинку стула и отметить еще одну победу. Считайте, что ваш оппонент позорно бежал. Продолжать сей спор показывает — не показывает без указаний на конкретные огрехи кода считаю бессмысленным.
Проблема в том, что многие элементы отрабатывают разные сценарии по наведению указателя и по нажатию. Проще говоря, эффектом hover на ссылке мы успеем насладиться ровно до того момента, пока не произойдет переход.
Гипертекст, формально говоря, — это текст со ссылками на другие гипертексты (википедия).
Гипермедиа, отвечающая за «H» в HATEOAS, в свою очередь, в любом REST сервисе используется практически всегда, так как в нее входят помимо размеченного текста еще и медийные ресурсы (фото, аудио, видео)
Есть api-blueprint-preview для Atom'а, но лично не тестировала.
А по коммиту в репозиторий файлы склеиваются в один и публикуются на apiary
Фактически, использование именно сервиса Apiary (и формата apiblueprint, как следствие) обусловлено необходимостью иметь актуальную документацию по API с минимальной тратой ресурсов на ее поддержание.
С учетом того, что код покрыт модульными тестами (прекондишены мы тестируем именно там), достаточно видеть, что API возвращает что-то более-менее похожее на правду.
Единственное, что мне нужно было — это преобразовать markdown разметку в html. Showdown это и делает, это и ничего больше.
2. Загрузятся две. Предыдущая и запрошенная.
3. На своем сервере потребовалось бы поднять свой git, к нему делать отрисовку логов, давать возможность watch. По поводу скорости: сайт с большой картинкой на первом экране и svg на странице (суммарно 500кб) + шрифт, пару скриптов в т.ч. с шарилками. Сервер тут вообще не причем — он быстро все отдает.
4. А если вы в книгу человек закладку вложить забудет? Пока сложно сказать, есть ли нужда в карте. Технически — реализуемо и быстро (все есть в конфиге — нужно только вывести по порядку).
5. Да. В данном случае нет задачи поддержать пользователей IE, Edge и старых версий — целевая аудитория продукта не та, да и я лично против поддержки кривого по.
А на мой вопрос вы так и не ответили…
Согласна с вами насчет кода, куда ж без правок.
Ну и так, чтобы закрыть тему: я не ищу работу ни джуниором, ни кем ли бы то ни было и не претендую ни на ваши места, ни на ваши заслуги. Можете откинуться на спинку стула и отметить еще одну победу. Считайте, что ваш оппонент позорно бежал. Продолжать сей спор показывает — не показывает без указаний на конкретные огрехи кода считаю бессмысленным.