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

Re: [rest-discuss] URL-Design: Structured Resources vs. Searching Globally

Expand Messages
  • Stefan Tilkov
    ... Yes, or it could be or or whatever. ... Exactly! ... It s tempting to
    Message 1 of 7 , Nov 1, 2007
    • 0 Attachment
      On Oct 31, 2007, at 11:35 PM, Stefan Hübner wrote:

      > On 30/10/2007, Stefan Tilkov <stefan.tilkov@...> wrote:
      > [snip]
      > > I see nothing wrong with having both options -- i.e. /products is
      > the
      > > collection resource for all products, and /companies/{id}/products
      > is
      > > the company-specific one. I assume that in both cases, you'd
      > return a
      > > list of links.
      >
      > OK. So /products would return e.g. XML like
      > <products>
      > <product xlink:href="/companies/1/products/1" />
      > <product xlink:href="/companies/1/products/2" />
      > <product xlink:href="/companies/2/products/1" />
      > <product xlink:href="/companies/3/products/1" />
      >
      > ... and so on, right?
      >
      >

      Yes, or it could be

      <product xlink:href="/products/1" />

      or

      <product xlink:href="/AD5EFFAE132865DDE" />

      or whatever.

      > On my way home just after posting my my first mail, I realized I
      > should look at the application from a Website-point-of-view. Meaning:
      > there can be several lists of similar things in different places of
      > the application. As long as they link to valid documents and clients
      > get what they expect when traversing those links.
      >

      Exactly!

      >
      >
      > > Beware of over-emphasizing URI meaning, though -- it's nice to have
      > > readable URIs, but they shouldn't "leak" into your design.
      >
      > Could you please explain your point a bit?
      >
      It's tempting to start first REST projects with obsessive URI design,
      but as Hugh pointed out by now, too, client-side URI construction is
      always a bad sign (unless the client has received instructions on how
      to construct the URI dynamically).

      Stefan
      --
      Stefan Tilkov, http://www.innoq.com/blog/st/
    • A. Pagaltzis
      ... I *would* suggest that it is implemented that way. It’s the hypermedia constraint. Truly RESTful apps are – by definition![1] – designed around the
      Message 2 of 7 , Nov 1, 2007
      • 0 Attachment
        * Hugh Winkler <hughw@...> [2007-11-01 12:02]:
        > I admit I'm not sounding very convincing with this argument,
        > because I'm asking you a) to have clients make an extra GET
        > first to retrieve the form, and b) they still have to have some
        > foreknowledge of the element name attributes they should
        > understand. It does however insulate them from having to
        > understand the form of your urls.
        >
        > I guess I'm putting this out here for discussion, and not
        > really suggesting you implement it this way.

        I *would* suggest that it is implemented that way. It’s the
        hypermedia constraint.

        Truly RESTful apps are – by definition![1] – designed around
        the formats of the representations exchanged, not around the
        structure of the URIs used.

        Take a look at Atompub for an idea of how that looks in practice.

        > But if anyone out there thinks there's a good way to do what
        > I'm trying to do, which is to drive the interaction through
        > forms, please jump in.

        I think what you described is just fine.


        [1] Remember what “ReST” means…

        Regards,
        --
        Aristotle Pagaltzis // <http://plasmasturm.org/>
      • Patrick Mueller
        ... Yeah, not sounding terribly convincing to me. I do think your described solution is fine, as long as there really isn t a need for machine to machine
        Message 3 of 7 , Nov 1, 2007
        • 0 Attachment
          Hugh Winkler wrote:
          > I admit I'm not sounding very convincing with this argument, because
          > I'm asking you a) to have clients make an extra GET first to retrieve
          > the form, and b) they still have to have some foreknowledge of the
          > element name attributes they should understand. It does however
          > insulate them from having to understand the form of your urls.
          >
          > I guess I'm putting this out here for discussion, and not really
          > suggesting you implement it this way. But if anyone out there thinks
          > there's a good way to do what I'm trying to do, which is to drive the
          > interaction through forms, please jump in.

          Yeah, not sounding terribly convincing to me. I do think your described
          solution is fine, as long as there really isn't a need for 'machine to
          machine' communication.

          Actually, let's discuss this 'machine to machine' communication. I
          think what you're actually talking about is 'all other forms of
          client-server interaction for this application other than an HTML page'.
          I mention this because I get this sense that people think 'machine to
          machine' communication is bad, when in fact, it's quite good. The more
          clients, the merrier.

          I think once you've decided that you'd like to open your 'server
          application' up to more than just the HTML pages you provide, you really
          do need to describe your REST APIs *somehow* (the urls, and the data
          flowing over the wire). We'll obviously never agree on *how*, I'm not
          going to go so far as to suggest that's possible. :-)

          Hugh's right that you can glean some of this information from a
          plain-old HTML form. Perhaps lightly enhanced via MicroFormats or some
          such, a form really could serve as a per-API meta-description of the API
          itself. Interesting idea.

          On the other hand, pretend that you've actually described your APIs
          (URLs and the data that flows through them) in some kind of
          program-readable fashion. From this, it would be easy to dynamically
          build a form, in JS on the client. Is there a difference?

          --
          Patrick Mueller
          http://muellerware.org
        Your message has been successfully submitted and would be delivered to recipients shortly.