Каковы соглашение о присвоении имен параметров URL или стандарты для следования
Простые триггеры нельзя использовать для процессов, требующих авторизации.
- Ссылка Проверьте 4-ую точку маркера.
Чтение немного дальше, в документации говорится:
Устанавливаемые триггеры для приложений G Suite концептуально похожи на простые триггеры, такие как onOpen (), но они могут реагировать на дополнительные события и ведут себя по-разному.
Например, устанавливаемый триггер открытия для Google Sheets активируется всякий раз, когда электронная таблица открывается любым пользователем, имеющим доступ к редактированию, так же, как простой триггер onOpen (). Однако, устанавливаемая версия может вызывать сервисы, требующие авторизации. Устанавливаемая версия запускается с авторизацией пользователя, который создал триггер, даже если другой пользователь с правами доступа открывает электронную таблицу.
6 ответов
Я рекомендую читать , Прохладный URI не Изменяется Tim Berners-Lee для понимания этого вопроса. При использовании параметров в URI могло бы быть лучше переписать их для отражения то, что на самом деле означают данные.
Так вместо того, чтобы иметь следующее:
/index.jsp?isbn=1234567890
/author-details.jsp?isbn=1234567890
/related.jsp?isbn=1234567890
Вы имели бы
/isbn/1234567890/index
/isbn/1234567890/author-details
/isbn/1234567890/related
, Это создает более очевидную структуру данных и означает, что при изменении архитектуры платформы URI не изменяется. Без вышеупомянутой структуры,
/index.jsp?isbn=1234567890
становится
/index.aspx?isbn=1234567890
, что означает, что все связи на Ваш сайт теперь разорваны.
В целом, необходимо только использовать строки запроса, когда пользователь мог обоснованно ожидать данные, они получают, чтобы быть сгенерированными, например, с поиском. При использовании строки запроса для получения неизменного ресурса от базы данных, то используйте перезапись URL.
Нет никаких стандартов, о которых я знаю. Просто помните IE предел длины URL из 2 083 символов.
Стандарт для URI определяется RFC2396.
Что-либо после того, как стандартизированную часть URL оставляют Вам.
Вы, вероятно, только хотите следовать конкретной конвенции по своим параметрам на основе платформы, которую Вы используете.
Большую часть времени Вы даже действительно не заботились бы, потому что они не находятся под Вашим контролем, но когда они, Вы, вероятно, хотите, по крайней мере, быть последовательными и попытаться генерировать удобные для пользователя биты:
- , которые коротки,
- , если они предназначены, чтобы быть непосредственно доступными пользователям, их должно быть легко помнить,
- нечувствительный к регистру (может быть твердым в зависимости от сервера ОС).
- следуют приблизительно за инструкции по SEO и лучшие практики , они могут помочь Вам много.
я сказал бы, что чистота и удобный для пользователя является похвальными целями бороться за при представлении URL.
StackOverflow делает довольно хорошее задание его.
Я использую нижний регистр. В зависимости от технологии Вы используете, QS любой threated как чувствительный к регистру (например, PHP) или не (например, ASP). Используя нижний регистр избегает возможного беспорядка.
Как другие ответы я не услышал ни о каких конвенциях.
единственный "стандарт", которого я придерживался бы, должен использовать больше поисковой системы дружественная практика использования URL rewriter.
Нет никаких стандартов, о которых я знаю, и случай не должен иметь значения.
Однако в рамках Вашего приложения (веб-сайт), необходимо придерживаться собственных стандартов. Для Вашей собственной исправности, если ничто иное.