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

Re: [rest-discuss] Collections and special cases

Expand Messages
  • Jan Algermissen
    ... Yes. You can think of query parameters to work sort of like the WHERE-condition in an SQL select statement. ... The issue with using a new URL path segment
    Message 1 of 3 , Jan 14, 2013
    • 0 Attachment
      On 14.01.2013, at 11:10, "risseraka" <risseraka@...> wrote:

      > The study case is where you have a collection of programs and you are trying to get the currently running program out of this collection.
      >
      > Till now, I have come up with two solutions:
      >
      > 1. /programs?current
      > 2. /programs/live
      >
      > 1. can be understood like applying a sort of filter on the "programs" collection using a "current" query parameter.

      Yes. You can think of query parameters to work sort of like the WHERE-condition in an SQL select statement.

      >
      > 2. uses the /entities/{id} schema with a non numerical id, "live".

      The issue with using a new URL path segment is that the path segment hierarchy in a URL *does* have a meaning - '/' is not just *any* character. So you can think of /{id} in your case to be a sub-'bucket' of your overall 'entities' space.

      >
      > Whereas my personal preference goes for the first solution, my guts get a bit fuzzy with trying to get a single item hitting directly on the collection end-point.

      Agreed - your scenario is 'indexing' into the collection not a 'sub bucket'. You could, of course, argue about this a lot - here are two things to consider:

      - do you maybe have more filters that work in parallel? This makes the first solution obviously better.
      - Implementation-wise the first solution is usually cleaner, because {id} will always denote an ID in your code, no special if(id == "live") needed.

      >
      > In both cases a 302 Moved Temporarily is performed(?) to redirect to the live program's URI, /programs/1234 with "1234" being the current program's id.

      Yes, makes sense.


      Jan


      >
      > I hope I'm not making a complete fool out of myself and the entire REST community.
      > Thanks in advance for your patience!
      >
      > Adrien.
      >
      >
    • risseraka
      ... I m not sure if you mean parallel as in mutualy exclusive or as in combinative . There is a case where a program is looked up by a timestamp with an
      Message 2 of 3 , Jan 24, 2013
      • 0 Attachment
        --- In rest-discuss@yahoogroups.com, Jan Algermissen wrote:
        >
        >
        > On 14.01.2013, at 11:10, "risseraka" wrote:
        > > Whereas my personal preference goes for the first solution, my guts get a bit fuzzy with trying to get a single item hitting directly on the collection end-point.
        >
        > Agreed - your scenario is 'indexing' into the collection not a 'sub bucket'. You could, of course, argue about this a lot - here are two things to consider:
        >
        > - do you maybe have more filters that work in parallel? This makes the first solution obviously better.

        I'm not sure if you mean parallel as in "mutualy exclusive" or as in "combinative".

        There is a case where a program is looked up by a timestamp with an "at" parameter.
        If "current" and "at" parameters are used together, "current" will take precedence over "at" and redirect accordingly to the current program.

        I have pondered on solutions like /programs?at=1359000000 and /programs?at=now but am not convinced.

        > - Implementation-wise the first solution is usually cleaner, because {id} will always denote an ID in your code, no special if(id == "live") needed.

        Indeed, if(id == "live") is a pain whereas if(query.current) is much smoother.

        > >
        > > In both cases a 302 Moved Temporarily is performed(?) to redirect to the live program's URI, /programs/1234 with "1234" being the current program's id.
        >
        > Yes, makes sense.
        >
        >
        > Jan

        Adrien.
      Your message has been successfully submitted and would be delivered to recipients shortly.