JSON получил широкое распространение прежде всего потому, что он предлагает способ обойти политику того же происхождения, которая используется в веб-браузерах, и тем самым разрешить гибридные приложения.
Допустим, вы пишете веб-сервис в домене A. Вы не можете загружать XML-данные из домена B и анализировать их, потому что единственный способ сделать это - XMLHttpRequest, а XMLHttpRequest изначально был ограничен тем же источником политика обращения только к URL-адресам в том же домене, что и содержащая страница.
Оказывается, по ряду причин вам разрешено запросить < script > теги по происхождению. Умные люди поняли, что это хороший способ обойти ограничение с XMLHttpRequest. Вместо того чтобы сервер возвращал XML, он может возвращать серию литералов объектов и массивов JavaScript.
(бонусный вопрос оставлен читателю в качестве упражнения: почему < script src = "..." > разрешен для доменов без согласия сервера, а XHR - нет?)
Конечно, возвращая < скрипт > который состоит только из объектных литералов и не полезен, потому что, не присваивая значения какой-либо переменной, вы ничего не можете с этим сделать. Таким образом, большинство служб используют вариант JSON, называемый JSONP ( http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/ ).
С ростом популярности гибридных приложений люди поняли, что JSON является удобным форматом обмена данными в целом, особенно когда JavaScript является одним из концов канала. Например, JSON широко используется в Chromium даже в тех случаях, когда C ++ находится на обеих сторонах. Это просто удобный способ представления простых данных, для которых существуют хорошие парсеры во многих языках.
Забавно, используя < script > теги для создания гибридных приложений невероятно небезопасны, потому что они, по сути, специально предназначены для XSS. Таким образом, родной JSON ( http://ejohn.org/blog/native-json-support-is-required/ ) должен был быть представлен, что устраняет первоначальные преимущества формата. Но к тому времени это было уже супер популярно :)
Мне следовало проявить немного больше терпения, прежде чем задавать этот вопрос, потому что я нашел ответ:
(r'^(?P<object_id>\d+)/$', 'django.views.generic.list_detail.object_detail', info_dict),
(r'^(?P<object_id>\d+)/(?P<slug>[-\w]+)/$', 'django.views.generic.list_detail.object_detail', info_dict),
Первый шаблон разрешает URL-адреса в форме / article / 1 /, что означает, что второй шаблон URL (для включения заголовка) является необязательным.