Loading ...
Sorry, an error occurred while loading the content.

19637Re: [rest-discuss] Resources and presentation views

Expand Messages
  • Erik Wilde
    May 7, 2014
    • 0 Attachment
      hello 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 ?
      > /Reports/1/PieChart
      > /Reports/1/Histogram

      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 |
    • Show all 2 messages in this topic