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

5019Re: [rest-discuss] The role of queries in REST?

Expand Messages
  • S. Mike Dierken
    May 6, 2005
       
      > By implementing this hierarchy [...]
      > This is, of course, standard REST.
      REST doesn't encompass implied hierarchical relationships between resources, just explicit linked relationships (hypertext).
       
      > how would the Web site support the many kinds of queries that a user might want to make
      > "Tell me all the Aircraft that carry Bomb1"
      It's not really the queries that are important, but the results (minor point, I know).
      Giving identity to each and every interesting result is the first step. Returning a representation of those identified results are how a Web site supports all the queries a user might want to make. That's all there is to it - that's the integration point.
       
      However, the way the client app acquires that identifier is the next interesting part - hyperlinking is one way, but not that great with an enormous numbers of resources. Constructing that identifier is another way - which is what you are describing. (I've a feeling we've all heard this before). HTML Forms are a simple description of how to construct that resource identifier. There can be other ways to describe how to construct identifiers - like the OpenSearch stuff from A9.
       
      > The Web site parses the form to extract the query, processes it, and returns the results to the user.
      The client app parses the form, not the site. It does this in order to determine the rules for constructing the resource identifer - and those rules imply user interaction. It's usually a really simple name/value pair kind of interaction, but sometimes it's an interactive graphic where a user's mouse click provides coordinates as inputs to generate a resource identifier. (Someday someone will buy a clue and go crazy with defining new widgets for use in a browser.) The browser constructs the resource identifier then retrieves the specified results.
       
      > How can a Web site possibly provide a form for every conceivable kind of query? 
      > It would be impossible to anticipate every kind of query that users might want to make.
      That's the job of a Web site though - anticipate what information users want and make it easily accessible. Not all access is required to go through a query - the site can simply use hyperlinks on pages. Those hyperlinks can be put in context where a person (or a machine) can understand what kind of results they point to. This is the 'information architecture' aspect of Web design - when to use categorized links and when to use user input based search.
       
       
      > So when we start talking about a user filling in a form we are either talking about a "form resource" or we
      > are breaking away from the REST model
      Not at all. A form is merely a way to generate a resource identifer based on user input. The page that has the form to be filled in is a 'help me locate a resource' type of resource. Pages full of links and explanatory text are also 'resource locator' resources.
       
      > If we are talking about a "form resource" then how would it fit into the above mission resource hierarchy?
      The hierarchy of names in the example shouldn't restrict how users can search for information - like you've mentioned, ad hoc searching should be possible. I don't think a page with a form on it has to be a resource distinct from any of the others. Each representation (web page) can have multiple exit points - some as simple hyperlinks, some as search forms, possibly multiple seach forms on a single page.
       
      > I believe that it is not appropriate in REST to talk about forms. 
      It's very appropriate to talk about forms. They are an assistant to hyperlinking. They can also be considered a 'service description language' (in the same way that Perl is considered by some to be a programming language).
       
      > I believe that with the REST model the idea of issuing queries doesn't make sense.
      Very very true. A client doesn't 'issue a query' - it retrieves results.
       
      > One solution is: this is a user processing issue, not a Web site resource issue, so it is outside the scope of REST.
      This is indeed a user processing issue, and to be useful on the Web it is a good idea to be RESTful.
       
      >In other words, if a user wants to know what aircraft carry Bomb1 then it is up to the user to retrieve each
      > aircraft resource and do processing on each aircraft resource to determine if it carries Bomb1.
      If the designer of the Website did not consider that kind of use, then the poor audience has no choice. The interesting thing is that it is still possible, just boring. But spiders don't get bored.
      However, if the website designer considered this use case, then they can design the resource space to include this kind of result.
       
       
    • Show all 20 messages in this topic