Denis Smirnov: ну вот я и отвечаю, что если хотите скрыть адрес сайта, откуда отправили запрос (http referrer, то есть), то отправляете исходные данные не на целевой сервер, а какой-нибудь подконтрольный вам, и переделываете запрос как вам нужно - убираете реферрер...
Denis Smirnov: именно какой-нибудь промежуточный сервер. Смысл в том, что с браузера пользователь отправляет данные вам (на тот же сервер, откуда заполнял форму, или на другой, не важно) и вы на этом сервере формируете такой запрос, какой вам надо (в конкретном случае, с таким реферером, как необходимо)
Ewoqq: Потому на это и акцентировал внимание :) И потом я и написал, что это самый простой способ.
Понятие - очень много, тоже ничего не значит без конкретных цифр. Если у вас 50 полей на физлицо, 50 полей на юрлицо и ожидается, что всего будет 10000 пользователей, то пережить явно можно будет
raiboon: Очевидно же, избавиться проверкой на наличие этого виджета на странице. По-хорошему, JS должен взаимодействовать только с data-атрибутами. Есть дата-атрибут - нужно работать. Нет дата-атрибута - не нужно работать.
Если запрос делается до такой проверки - это плохой дизайн. И разделение по файлам спасет лишь незначительно.
Время на поиск... Ну, тут вы правы, эти спички редко считают.
raiboon: Ну так 2 варианта: селектора нет - происходит поиск по дерево и завершение. Селектор есть - происходит поиск и "инициализация". В чем проблема? Боитесь, что на одних страницах одни и те же селекторы нужно обрабатывать, а на других - нет ? Это проблема дизайна уже, а не файловой структуры.
Ivan: формат сообщения - это просто один из "побочных" эффектов, не играющий практически никакой роли. habrahabr.ru/post/38730 Начните, например, отсюда
Кратко: главный смысл - иное представление ресурсов приложения. Сравнивать REST нужно с не x-form-urlencoded etc., а с RPC, к примеру.
rockdev: епт, я ж вам дважды написал, что можно, но это другой подход. Не бывает идеальных решений. Бывают инструменты, которые подходят лучше или хуже для определенной задачи.
Если вас интересует, в чем разница, и какие преимущества\недостатки рендеринга на клинте\сервере - то так и формулируйте и задавайте новый вопрос.
thepry: Поверьте, это удобно, когда ты - "писатель". Когда читатель - уже нет.
А выражения довольно часто становятся не-однострочками
Я не призывая переписывать каждую строчку, но лучше помнить, представлять, сколько шансов, что все равно скоро перепишешь, и держать в голове, что читать сверху-внизу-слева-направо - привычнее, по крайней мере для нас.
thepry: читабельнее. плюс, очень часто строчка может превратиться в две и все равно нужно будет переписывать инлайновое условие.
инлайновые условия смотрятся очень красиво, пока не дойдет до поддержки
Hitsuzen: неделя поиска первой работы - это как бы не проблема. Просто пробуйте. На самом деле, умение проходить собеседование не очень тесно связано со скилами по работе.
Поставьте себе сначала цель просто пройти, скажем, 10 собеседований. Тогда все и станет быстро на свои места. Что вакансий в питере нет, не поверю. Смотрите hh.ru и подобное
Николай Марков: Может, я не так выразился, конечно, но, мне кажется, что под публичным - имеется ввиду для всех подряд. Под приватным - по приватному апи ключу. Например, когда вы делаете бэкэнд и мобильное приложение.
Разница в чем. В том, что в этом случае, все вопросы, которые появляются у пользователей АПИ - вы 100% обязаны решать в кратчайшие сроки.
Николай Марков: все ,что вы перечислили - это инструменты. Блокнот + гит на крайняк нормально подойдет, если работаете один. А вот википедия будет оверхедом.
Mashape и swagger - хорошее решение, когда делаете качественное публичное апи, которым будут пользоваться, потенциально, тысячи сторонних разработчиков.
Если, скажем, вы делаете бэкэнд, а команда со стороны заказчика делает фронтэнд, апи у вас приватное и постоянно куча правок и неоднозначностей, где принимают участик как разработчики, так и заказчик\менеджеры\тестировщики - то здесь с википедией жизнь может быть проще.
vsuhachev: с валидациями, конечно, попроще. Хотя, больную тему рельс - валидацию уникальности - все равно придется вручную проверять, как минимум.
Но коллбэки - проблема серьезнее
tasce: конечно, вы от части правы, особенно про то, что исходить из задачи. Но нужно отметить, что питоны, пхп, а руби особенно - были и придуманы, что б 10 миллионов строк с вами никогда не случилось