Исходный шаблон дизайна для HTML

Question

Я стараюсь придерживаться шаблона для отдыха и JSON и HTML. Моя проблема - это дизайн для создания нового ресурса (в том числе, но это суть проблемы). IE:

JSON – POST to /resource creates a new resource. 
JSON – GET to /resource returns a list of resources. 
JSON – GET to /resource/{id} returns a resource. 
HTML – POST to /resource creates a new resource. 
HTML – GET to /resource returns a list of resources. 
HTML – GET to /resource/{id} returns a resource. 

Все хорошо до сих пор - но мне нужна форма HTML, чтобы фактически создать данные для отправки в ПОЧТУ HTML. Очевидно, POST и GET уже делают что-то. Я мог бы использовать один из ниже, чтобы вернуть форму HTML:

HTML – GET to /resource?CREATE 
HTML - GET to /resource?action=CREATE 
HTML – GET to /resources/CREATE 

Но они, кажется, как ляп и не то, что интуитивно. Любые мысли или идеи?

EDIT - см. Мой ответ на мой вопрос ниже. В настоящее время это (я считаю) лучшим вариантом.

Answer 1

У меня есть ответ. Я буду использовать стандартный RESTful POST с HTML-страницы, но когда у меня нет параметров формы, и мой заголовок accept - text/html, я отправлю HTML-форму запрашивающему. Сохраняет дизайн URI RESTful и позволяет создать чистую HTML-форму + процесс (2 шаг).

HTML - POST - /resources (with no form attributes) generates a HTML form 
HTML - POST - /resources (with form attributes) adds a resource 
JSON - POST - /resources (with form attributes) adds a resource 

ОК, это не «строго» RESTful, как я отправляю, но не создает новый ресурс, так что в теории я должен использовать GET для этого, но это лучшее из спаренной конструкции.

Если кто-то может обеспечить лучшее решение, я до сих пор все уши :-)

Answer 2

Я бы действительно использовал что-то вроде /resources/create. Если вы хотите разрешить использование нечисловых идентификаторов, это не сработает. В этом случае вы можете определить ресурс с префиксом, например /resources/resource-{id}, а затем вы можете использовать /resources/create.

Я нашел этот блог очень полезно сделать URI схемы решения: http://blog.2partsmagic.com/restful-uri-design/

Answer 3

В самом деле, вы должны LEVERAGE согласование содержания (CONNEG), если вы хотите работать с несколькими форматами в RESTful услуг.

Я имею в виду:

• Установить заголовок Content-Type указать тип переданных данных
• Установите заголовок Accept, чтобы указать тип данных, которые вы хотите получить

ресурсов сервера должны использовать эти подсказки для обеспечения соответствующего преобразования данных.

В случае JSON тип содержимого будет, очевидно, application/json. Для формы HTML вы должны использовать тип контента application/x-www-form-urlencoded (или multipart/form-data, если хотите загрузить файлы). См. the specification для получения более подробной информации.

В противном случае вы не должны использовать действие в URL-адресе, так как оно не является RESTful. Глагол HTTP должен определить действие, которое необходимо выполнить для ресурса. Я хочу сказать, что для создания ресурса следует использовать метод POST. Метод GET направлен на получение состояния ресурса.

Для получения более подробной информации вы можете посмотреть на этом блоге:

• Designing a Web API (т.е. RESTful услуги).

Answer 4

Я предпочел бы добавить и конечная точка называется /templates/, которая возвращает шаблон/форму/все, что нужно для данного действия. Также кажется, что сервер не должен знать о существовании такой формы. Он может принять или отклонить запрос и его клиентскую работу, чтобы отправить его в соответствующем формате.

Я предполагаю, что вы смешиваете обработку представления с подготовкой конечных точек RESTful. Бэкэнд-сайт должен полностью не знать о том, что требуется какой-то вид/форма. Это клиентская работа по подготовке такой формы.