El diseño de las direcciones URL de descanso para páginas web

Question

tutoriales más REST recursos dispuestos de la siguiente manera:

GET /car/  -> list of cars 
GET /car/<id>/ -> info about specific car 
POST /car/  -> create a new car 

pero cuando la creación de aplicaciones web para su uso en navegadores, hay un eslabón perdido que rara vez se discute, antes de enviar a/coche /, necesita OBTENER un formulario para crear un nuevo recurso (automóvil). ¿Cuál debería ser la URL de este formulario?

que normalmente solía:

GET /car/new/ -> form for creating a new car 
POST /car/new/ -> redirect to /car/<id>/ if item is created else show form with invalid fields highlighted 

pero según http://www.slideshare.net/Wombert/phpjp-urls-rest esto no es una buena URL REST. Puedo ver por qué no es un buen RESTO, porque "nuevo" realmente se usa como verbo y no como recurso, pero dónde debe estar el formulario, porque GET /car/ ya se usa para enumerar autos, por lo que no se puede usar GET /car/ para la forma de los autos nuevos

En resumen, mi pregunta es: "¿Cuál es la URL RESTANTE para 'crear formulario de recurso'?"

En una nota ligeramente relacionada, incluso en un servicio web, a veces no siempre es prudente confiar en que el cliente conozca el esquema de antemano, por lo que incluso en los servicios web podría ser necesario que el cliente solicite el esquema actual del recurso. AFAICS, esto como una situación similar con la necesidad de OBTENER un formulario de creación (es decir, el formulario es algo así como un esquema que describe cómo construir una consulta POST para crear el recurso). ¿Mi línea de pensamiento aquí es correcta?

Answer 1

REST no le importa demasiado cómo se verá su URI siempre que identifique un recurso único y se autodescriba. Cumplir con esos criterios, y más allá de eso, es una preferencia personal. Nada prohíbe usar un verbo en un URI si tiene sentido usar uno.

En cuanto a su nota ligeramente relacionada, lo que sugiere con el formulario es un esquema tipo de medio. La arquitectura RESTful se refiere tanto al cliente como al servidor que entienden los tipos de medios utilizados para representar el estado de la aplicación.

Una API REST debe pasar la mayor parte de su esfuerzo descriptivo en definir el tipo (s) de medios utilizados para la representación de los recursos y la conducción estado de la aplicación, o en la definición de nombres de relaciones extendidas y o marca/hipertexto habilitado para los tipos de medios estándar existentes. Cualquier esfuerzo empleado describiendo qué métodos usar en qué URI de interés debe estar completamente definido dentro del alcance de las reglas de procesamiento para un tipo de medio (y, en la mayoría de los casos, ya definido por los tipos de medios existentes).

leer más aquí: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Eso es de Roy Fielding, el hombre que definió RESTO. En general, sus tipos de medios deben ser extensibles, es decir, cualquier cambio debe agregar y no interrumpir a los clientes más antiguos a menos que sea necesario.

Answer 2

Siempre asumí que "formulario" como tal no es un recurso, por lo que /<name>/new está bien - los formularios no son elementos habituales de las API. El autor de las diapositivas puso eso en una "mala" lista, pero no proporcionó una correcta, supongo que fue tan RESTANTE que olvidó pensar en tales casos.