FAQ
Quick question, and I hope this doesn't turn into a debate about REST
specifics, just looking for a sane URL scheme.

Say I have an app for managing technical conferences. There's one "user"
table. A "user", of course, can be both a presenter and an attendee of
sessions. So, I want to get a list of sessions a user is associated with,
but also want to get separate lists for sessions they are a presenter for
vs. sessions they are just attending.

In the db there's attendee_session and presenter_session link tables to
associate users with the sessions.

This seems a bit ambiguous, plus not sure what to do if a user happens to be
a presenter AND an attendee of the same session.

GET /user/1234/sessions


And these seem wrong because the query parameter is about the user not the
session. That is, seems like any query parameters should be limiting on the
session (e.g. session_type).

GET /user/1234/sessions?user_type=attendee
GET /user/1234/sessions?user_type=presenter


Other options would be:

GET /user/1234/sessions_attending
GET /user/1234/sessions_presenting



What would you use?


--
Bill Moseley
moseley@hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110518/dbf2a08a/attachment.htm

Search Discussions

  • Devin Austin at May 18, 2011 at 4:54 pm

    On Wed, May 18, 2011 at 10:22 AM, Bill Moseley wrote:

    Quick question, and I hope this doesn't turn into a debate about REST
    specifics, just looking for a sane URL scheme.

    Say I have an app for managing technical conferences. There's one "user"
    table. A "user", of course, can be both a presenter and an attendee of
    sessions. So, I want to get a list of sessions a user is associated with,
    but also want to get separate lists for sessions they are a presenter for
    vs. sessions they are just attending.

    In the db there's attendee_session and presenter_session link tables to
    associate users with the sessions.

    This seems a bit ambiguous, plus not sure what to do if a user happens to
    be a presenter AND an attendee of the same session.

    GET /user/1234/sessions


    And these seem wrong because the query parameter is about the user not the
    session. That is, seems like any query parameters should be limiting on the
    session (e.g. session_type).

    GET /user/1234/sessions?user_type=attendee
    GET /user/1234/sessions?user_type=presenter


    Other options would be:

    GET /user/1234/sessions_attending
    GET /user/1234/sessions_presenting



    What would you use?


    --
    Bill Moseley
    moseley@hank.org

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    I'd personally use /user/1234/sessions/attending and
    /user/1234/sessions/presenting

    --
    Devin Austin
    http://www.codedright.net
    9702906669 - Cell
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110518/22d83a4e/attachment.htm
  • Alejandro Imass at May 18, 2011 at 6:24 pm

    On Wed, May 18, 2011 at 12:22 PM, Bill Moseley wrote:
    Quick question, and I hope this doesn't turn into a debate about REST
    specifics, just looking for a sane URL scheme.
    Say I have an app for managing technical conferences. ? There's one "user"

    Parameters and stuff are all not that important if the parameters are
    conditions / extra information needed to retrieve/update the resource.
    In your case I don't think it makes much difference, except for the
    way you will handle your parameters in the controllers. The important
    ideas about REST URLs is that they do not contain verbs but always
    point to a resource. Resources are nouns and are usually used plural
    for collections and singular for a silgle resource. Parameters are
    fine IMHO and even encouraged so long as the params are not
    verbs of course ;-)
  • John M. Dlugosz at May 18, 2011 at 6:50 pm

    Parameters and stuff are all not that important if the parameters are
    conditions / extra information needed to retrieve/update the resource.
    In your case I don't think it makes much difference, except for the
    way you will handle your parameters in the controllers. The important
    ideas about REST URLs is that they do not contain verbs but always
    point to a resource. Resources are nouns and are usually used plural
    for collections and singular for a silgle resource. Parameters are
    fine IMHO and even encouraged so long as the params are not
    verbs of course ;-)
    I think the words on the URL matter, not as pure parameters, but in matching the "chained"
    actions of your design.
  • Alejandro Imass at May 18, 2011 at 7:32 pm

    On Wed, May 18, 2011 at 2:50 PM, John M. Dlugosz wrote:
    Parameters and stuff are all not that important if the parameters are
    conditions / extra information needed to retrieve/update the resource.
    In your case I don't think it makes much difference, except for the
    way you will handle your parameters in the controllers. The important
    ideas about REST URLs is that they do not contain verbs but always
    point to a resource. Resources ?are nouns and are usually used plural
    for collections and singular for a silgle resource. Parameters are
    fine IMHO and even encouraged so long as the params are not
    verbs of course ;-)
    I think the words on the URL matter, not as pure parameters, but in matching
    the "chained" actions of your design.
    Yeah, let me re-phrase. The REST URLs must look more like paths on a
    drive rather than an API. The URL parameters can be used freely (and
    must be used in many cases) as extra information for the GET request.
    For example, for filtering a collection, for conditioning the result,
    the presentation and in general for _conditioning_ the GET.
  • Alejandro Imass at May 18, 2011 at 7:43 pm

    On Wed, May 18, 2011 at 3:32 PM, Alejandro Imass wrote:
    On Wed, May 18, 2011 at 2:50 PM, John M. Dlugosz wrote:
    [...]
    Yeah, let me re-phrase. The REST URLs must look more like paths on a
    drive rather than an API. The URL parameters can be used freely (and
    must be used in many cases) as extra information for the GET request.
    For example, for filtering a collection, for conditioning the result,
    the presentation and in general for _conditioning_ the GET.
    I want to point out that the OP only referred to the GET URL.

    Furthermore, let's remember that in HTML 4 forms are a usually
    representation of a resource (the representation is actually HTML but
    the form usually presents data to the user). In other words, forms in
    HTML 4 are the only way to serialize data, or to represent data in the
    HTML doc. XHTML offers more, but in the end most interactions in Web
    1.0 and Web 1.5 (just to give a name to Web 1.0 + AJAX), are done with
    the html form artifact. This limits you to GET and POST for the action
    method of the form. anything you want to do RESTful (PUT, HEAD,
    DELETE) will probably require the use of JavaScript and some other
    serialization scheme (XML or JSON, I prefer the latter for many
    reasons).

    So then your resources as such would be invisible to your browser URL,
    maybe or maybe not depending on your far REST you want to go. For full
    Web 2.0 REST your URL in the browser would probably point to the
    application URL, that is an HTML Shell with a lot of JavaScript. The
    interactions from there on will be AJAX from JS and your URL in the
    browser would probably not change that much and your resources will be
    XML or JSON. Beleive it or not this actually more "Web"/REST that what
    we have today!

    Best,

    --
    Alejandro Imass
  • John Beppu at May 22, 2011 at 6:52 pm

    On Wed, May 18, 2011 at 9:22 AM, Bill Moseley wrote:
    Other options would be:

    GET /user/1234/sessions_attending
    GET /user/1234/sessions_presenting



    What would you use?
    Could you pull this off?

    GET /user/1234/sessions
    GET /user/1234/sessions/attending
    GET /user/1234/sessions/presenting
    GET /user/1234/sessions/attending+presenting

    This is similar to how del.icio.us handles tags.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110522/32f81c57/attachment.htm
  • Aristotle Pagaltzis at Jun 10, 2011 at 7:09 pm

    * Bill Moseley [2011-05-18 18:30]:
    And these seem wrong because the query parameter is about the
    user not the session.
    Why do you care?
    That is, seems like any query parameters should be limiting on
    the session (e.g. session_type).

    GET /user/1234/sessions?user_type=attendee
    GET /user/1234/sessions?user_type=presenter

    Other options would be:

    GET /user/1234/sessions_attending
    GET /user/1234/sessions_presenting

    What would you use?
    You are presenting a collection in all cases, and the list is the
    same in all cases. You are just filtering it differently.

    Use a query parameter.


    * John Beppu [2011-05-22 20:55]:
    Could you pull this off?

    GET /user/1234/sessions
    GET /user/1234/sessions/attending
    GET /user/1234/sessions/presenting
    GET /user/1234/sessions/attending+presenting

    This is similar to how del.icio.us handles tags.
    Attending + presenting = all. The first and last of these URIs
    mean the same thing.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMay 18, '11 at 4:22p
activeJun 10, '11 at 7:09p
posts8
users6
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase