Niclas Hedhman wrote:
>> /entity - listing of all Entities
> I think this one is a bad idea. Perhaps if some "development" mode is
> enabled, but not generally available (a lot of apps won't need
> security to stop it either).
>
>> /entity/<type> - listing of all Entities of the given type
> This one can be equally dangerous in production environments.
>
> Perhaps both of the above must be explicitly enabled per type, and/or
> a limit to how many instances to serve.
Yeah the security of this I'm not sure how to handle. But they are
certainly useful.
>> /entity/<type>/<id>.html - form for editing a specific Entity
>> /entity/<type>/<id>.rdf - RDF view of the specific Entity
>
> Personally, I don't like file extensions, especially from the days of
> IE implying so much from them (not sure what IE does nowadays). I
> guess that a path element is more REST-friendly than query arguments,
> so I would go for that.
The actual resources are at "/entity/<type>/<id>", so if you want to use
HTTP content negotiation ("Accept" header), that is indeed the preferred
way. The extension are only there as a form of explicit content
negotiation when you are accessing them from a client (such as a
browser) where you cannot set the Accept header.
I'm on the rest-discuss mailing list, and the conclusion from there is
that path elements should not be used to identity content types, only
actual resources. So, using content negotiation seems to be the most
RESTian way to do it, with extensions as the second choice, and Qi4j now
supports both.
> Again, should we have the .rdf extension?
>
> /type/org.qi4j.rest.test.TestEntity.rdf
> vs
> /type/org.qi4j.rest.test.TestEntity
See above. Both works, but the one without extension will right now
return HTML if you don't use Accept header to state what you want.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
