HTTP ИЗМЕНЯЕТ глагол для REST?
Обновление: django-конфигурации были выпущены, который является, вероятно, более оптимальным вариантом для большинства людей, чем выполнение его вручную.
, Если Вы предпочли бы делать вещи вручную, мой более ранний ответ все еще применяется:
у меня есть несколько файлов настроек.
-
settings_local.py- определенная для хоста конфигурация, такая как имя базы данных, пути к файлам, и т.д. -
settings_development.py- конфигурация, используемая для разработки, например,DEBUG = True. -
settings_production.py- конфигурация, используемая для производства, например,SERVER_EMAIL.
я связываю их все вместе с settings.py файл, который во-первых импортирует settings_local.py, и затем один из других двух. Это решает, чтобы загрузиться двумя настройками в settings_local.py - DEVELOPMENT_HOSTS и PRODUCTION_HOSTS. settings.py вызовы platform.node() для нахождения имени узла машины это работает, и затем ищет то имя узла в списках и загружает второй файл настроек, в зависимости от которого списка это находит имя узла в.
Тот путь, единственная вещь, о которой действительно необходимо волноваться, в курсе settings_local.py файл с определенной для хоста конфигурацией, и все остальное обрабатывается автоматически.
Выезд пример здесь .
4 ответа
Есть веская причина, по которой нет такого глагола для этого. Управлять практически невозможно. Подумайте о сотнях клиентов, изменяющих один и тот же ресурс таким образом, как узнать, где заканчивается ваша модификация? Что, если порядок имеет значение, и ваш «патч» фактически добавляется после другого «патча», и теперь то, что вы хотели добавить, на самом деле не то, что было добавлено. Использование PUT с заголовками ETag - это гораздо более разумный подход к изменению ресурса, чем попытка создать какой-то новый глагол с неизвестными результатами. Необходимость фактически ПОЛУЧИТЬ ресурс - это небольшая плата за воспроизводимые результаты.
Хотелось бы, чтобы были стандартизированные и поддерживаемые глаголы, такие как ...
- НАЙТИ, ПОИСК или ЗАПРОС - поэтому ясно, что запрос не для ресурса , а расположение других ресурсов. Может быть, только ограниченная полезность.
- MOVE, COPY, LINK - чертовски удобно, они действуют аналогично инструментам командной строки.
- DISCOVER, MAP, INDEX или SITEMAP - так что вы можете получить схему ресурсов, аналогично wsdl-файлу или xmlrpc system.listMethods.
- BEGIN, ACQUIRE или LOCK, и COMMIT, END, DONE или RELEASE - чтобы было ясно, когда вы начинаете и завершаете транзакции, или используете промежуточные ресурсы.
- ИЗМЕНИТЬ, ОБНОВИТЬ, ПАТЧ - потому что мы все этого хотим
Вы можете разделить ресурс на индивидуально обновляемые подресурсы.
Например, у вас есть / user , представляющий информацию об учетной записи пользователя, вы можете создать подресурс / user / email , а затем выполнить для него PUT, чтобы обновить только электронную почту.
Вы можете использовать POST для частичных обновлений. Это не идеально, но вполне RESTful.