URI и то, как вы их проектируете не имеет ничего общего с RESTful или нет.
Это обычная практика делать то, что вы просите, поскольку это то, как Apacheвеб-сервер работает .Допустим, у вас есть foo.txt, foo.html и foo.pdf, и вы запрашиваете GET /foo без каких-либо предпочтений (то есть без заголовка Accept:).300 MULTIPLE CHOICES будет возвращен со списком трех файлов, чтобы пользователь мог выбрать.Поскольку браузеры выполняют такие изумительные согласования контента, трудно сослаться на пример, но здесь идет речь: Пример показывает, как он выглядит, за исключением того, что причина, по которой вы видите страницу в первую очередь, заключается в другомслучай имени файла ("XSLT" против "xslt").
Но это поведение Apache отражено в соглашениях и различных инструментах, но на самом деле это не важно.У вас может быть people_html или people?format=html, или people.html, или sandwiches, или 123qweazrfvbnhyrewsxc6yhn8uk в качестве URI, который возвращает людей в формате HTML.Клиент не знает ни одного из этих URI заранее , он должен узнать об этом из других ресурсов.Человек может увидеть результат <a href="/sandwiches">All People (HTML format)</a> и понять, что происходит, игнорируя при этом странно выглядящий URI.
В заключительной заметке страница соглашений об URL-адресах микроформатов абсолютно не является спецификацией дляURL-адреса RESTful , это просто руководство по созданию URI, которые, очевидно, легко используются различными HTTP-библиотеками по тем или иным причинам и не имеют ничего общего с REST.Все рекомендации в порядке, и следование им делает ваши URI выглядящими вменяемыми другим людям, которые случайно заглядывают в URI (/sandwiches, по общему признанию, странный).Но даже цитируемый протокол AtomPub не требует, чтобы записи жили «внутри» коллекции ...