19637Re: [rest-discuss] Resources and presentation views
- May 7, 2014hello m.
On 2014-05-07, 10:22 , skyflymat@... wrote:
> 1.How does REST treat the notion of alternate presentation views for
> resource instances?
> For example suppose you want to model various views of a “Report” such
> as “Pie Chart” / “Histogram” .. that all share a common media type
> (text/html). How would such scenario be implemented using HTTP in
> RESTful way?
have a report resource that contains types links to the various views,
which are resources themselves. this allows clients to link to those
views, or to link to the more abstract general report. also, if
possible, include backlinks from the views, so that a client accessing a
view can find the general report resource.
> 2.Are resources required to expose a public URL or can they be thought
> of conceptually part of other resources Value Set without any URL?
> For example suppose that all Report views are modeled as dependent
> resource that are implicitly created when the client POSTS a Report to a
> Reports Collection, is there any requirement to maintain a URL for the
> Report resource instance itself such as /Reports/1 (assuming all access
> is limited through views) What would be a proper response to such HTTP
> POST ?
you could make /Reports a "POST-only" resource, but i'd suggest to keep
/Reports/1 around because
- it's a convenient starting place to find all view links
- it allows you to DELETE an entire report
- it may also link to or contain additional info such as a history or
whatever else may be interesting about a report apart from the views
> 3.According to the URL RFC 3986 different query strings produce
> different resource identifiers, is there any advantage to model
> alternate view resources using path components over query parameters or
> vice versa, (seems like same thing) ?
it's similar and to some extent, query strings are a historical aspect
of URI syntax. usually, people use paths when resource structure and
navigation is clearly hierarchical (and then being able to "hack" URIs
in the address bar can be very convenient), and query strings are used
when things get more complicated, such as multiple dimensions of how
resources are related. that being said, keep in mind that good REST
designs should not depend on specific URI patterns anyway, you should
have a logical view of how you interlink resources. using "pretty URIs"
then makes your service nicer to use, but your design should work in the
very same way, regardless of whether you use /Reports/1/pie or
erik wilde | mailto:dret@... - tel:+1-510-2061079 |
| UC Berkeley - School of Information (ISchool) |
| http://dret.net/netdret http://twitter.com/dret |
- << Previous post in topic