Обход пирамиды для запросов PUT

Я пытаюсь создать маршрут пирамиды для запроса PUT в API RESTful для создания нового ресурса. В моем приложении используется обход, который отлично работает для GET и POST:

config.add_route('myroute', '/resources/*traverse')

Поскольку PUT должно иметь новое имя ресурса в URL-адресе, это, очевидно, не работает с PUT, поскольку в конце есть неизвестный ресурс, поэтому обход не удается. Я попытался создать новый маршрут для PUT, используя гибридный подход к отправке и обходу URL:

config.add_route('myroute_put', '/resources/{path}/{new}', traverse='/{path}', request_method='PUT')

Это прекрасно работает тогда и только тогда, когда нужно пройти только сегмент пути. Имя нового ресурса доступно как request.matchdict['new'] Если мы находимся на корневом уровне, и нам нечего проходить, мы все равно можем заставить это работать, создав вспомогательный маршрут:

config.add_route('myroute_put_root', '/resources/{new}', reqeust_method='PUT')

Однако это не настоящее решение, потому что myroute_put по-прежнему не соответствует, если необходимо пройти более одного сегмента пути, например, для URL: /resources/path1/path2/new_resource


person drarmstr    schedule 23.12.2015    source источник


Ответы (1)


Этот вопрос о переполнении стека: Pyramid traversal HTTP PUT для URI, который не 't exists предлагает решение по созданию другого типа контекста NewResource для представления новых ресурсов. Метод __getitem__() класса Resource может всегда возвращать NewResource, если он не может найти запрошенный дочерний элемент. Затем можно настроить конфигурацию представления для контекста NewResource и PUT request_method.

Это почти работает, за исключением того, что всегда возвращается NewResource, когда дочерний элемент не найден, вместо поднятия KeyError нарушается возможность использования именованных представлений в качестве подчиненных URL. Например, URL: /resources/path1/path2/my_view ошибочно вернет контекст NewResource для my_view вместо того, чтобы использовать его в качестве имени представления, если оно существует.

Лучшим обходным решением этой проблемы, которое я нашел до сих пор, было создание пользовательского алгоритма обхода пирамиды, который сначала использует алгоритм обхода по умолчанию, но затем, если это не удается, он проверяет, является ли request.method PUT. Если это так, то он возвращает контекст NewResource, в противном случае он возвращает результаты обхода как есть.

person drarmstr    schedule 23.12.2015