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

Re: [rest-discuss] Bookmark 'stability'

Expand Messages
  • Peter Williams
    ... Really? (Talk about trolling.) How would you deal with the situation where a uri is acquired from search results? Search results change fairly often if you
    Message 1 of 60 , Sep 28 9:43 AM
    • 0 Attachment
      On Fri, Sep 28, 2012 at 9:14 AM, Steve Klabnik <steve@...> wrote:
      >> Some interactions which are simply repeatable. Ie, I go to bookstore api,
      >> pick the most popular book today and bookmark it. The every day the app
      >> checks and record its popularity so that I can see the trend over time. If
      >> that bookmark stops working the app is pretty much screwed.
      >
      > Sounds like someone should have written the app better.

      Really? (Talk about trolling.) How would you deal with the situation
      where a uri is acquired from search results? Search results change
      fairly often if you use modern search technologies like lucene, etc
      and are certainly not guaranteed to stay the same if new items are
      added that match the query. How should we procede when the client is
      given a url by a user or a third component of the (distributed)
      system? Surely we don't want to implement existing capabilities just
      so that we have all the information to refollow a hypermedia trail.
      The whole point of this exercise is to leverage the work and data of
      existing system.

      >> There many more situations like this once you get into building real
      >> applications.
      >
      > Nice troll. Well, I'm done here.

      It wasn't meant as a troll, i was merely pointing out that the two
      example i gave are not the only ones i have encountered.

      Peter
      barelyenough.org
    • Jan Algermissen
      ... Related to the discussion in general: http://digital.cabinetoffice.gov.uk/2012/10/11/no-link-left-behind/ jan
      Message 60 of 60 , Oct 14, 2012
      • 0 Attachment
        On Oct 8, 2012, at 2:04 PM, Nathan wrote:

        > Nathan wrote:
        > > Eric J. Bowman wrote:
        > >> Paul Cohen wrote:
        > >>> I mean that *forcing* a server to commit itself to maintaining URI:s
        > >>> is coupling.
        > >>>
        > >>
        > >> Maintaining obsolete URIs is not an example of "coupling" as applies to
        > >> REST. REST isn't "decoupled" but rather, "loosely coupled" around
        > >> standardized data types. The more obscure the data type, the tighter
        > >> the coupling. The more ubiquitous the data type, the looser the
        > >> coupling. What's being discussed is the degree of coupling between
        > >> client and server, not server and Web Developer. It gets very confusing
        > >> when participants in a discussion introduce their own definitions of
        > >> terms.
        > >
        > > An analogy may be your signs in the windows of your local shops, if one
        > > of them moves to a new premise, they could say nothing, or they could
        > > say "we've moved here" (30x). If they've got a new shop front on the
        > > other side, again they could post a sign to say "the doors now here". If
        > > they're closed they could say "closed" or "closed, were open again at
        > > 09:00". Regardless of the situation, if the place is closed, or gone,
        > > then leaving a note to provide some information will always help the
        > > client, and can be seen as good practise. You don't have to do it, but
        > > it sure makes sense to do it. Network protocol are just the same.

        Related to the discussion in general:

        http://digital.cabinetoffice.gov.uk/2012/10/11/no-link-left-behind/

        jan




        >
        > Point being, that it's nothing to do with coupling, it's just etiquette,
        > common sense, and good practise.
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.