[DAS2] [Bug 1806] New: When should DAS/2 URLs end with a '/'?

[bugzilla-daemon at portal.open-bio.org]

http://bugzilla.open-bio.org/show_bug.cgi?id=1806

           Summary: When should DAS/2 URLs end with a '/'?
           Product: BioDAS
           Version: 2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Spec - GET Requests
        AssignedTo: das2 at portal.open-bio.org
        ReportedBy: dalke at dalkescientific.com


Consider the following

  http://www.biodas.org/das/genome/human/0/type
  http://www.biodas.org/das/genome/human/0/region
  http://www.biodas.org/das/genome/human/0/feature
vs.
  http://www.biodas.org/das/genome/human/0/type/
  http://www.biodas.org/das/genome/human/0/region/
  http://www.biodas.org/das/genome/human/0/feature/

Which is to be preferred?  Should one be required
to redirect to the other and if so, which way?

I waver between the two.  One the one hand, the 
first grouping makes it easier to understand it
when parameters are passed to the URL.

  .../region?format=agp
  .../feature?type=exon

By comparison, the following looks strange, though
legitimate

  .../region/?format=agp
  .../feature/?type=exon

I did some research on this.  One site says
  http://www.markbaker.ca/2002/01/UriOpacityInvestigation/

============
The one standout thing about "/" when compared with the other separators, is that has a special 
meaning in the context of relative and base URI processing.

Relative URI are only relative because they are hierarchical. That is, "/wow/gee" is a relative URI, but 
when grounded to a base URI of;

http://example.org/foo/
yields an absolute URI of;

http://example.org/foo/wow/gee
This suggests that URI publishers should be concerned about whether their URI end in "/" or not. If the 
URI might ever be used as a container, it should end with "/". This also suggests that the relationship 
between a URI with a terminating slash, and the same URI without the terminating slash, is also nothing 
more than that same non-specific hierarchical relationship.

=============

In that case we should be using '/' for most of the URLs.

A problem comes in with subregions to a region.  When does a
subregion name end with a '/'?  Eg, if the following exists
(assuming there are no children under 128)

  .../region/ctg2/34/128

then what about

  .../region/ctg2
?

On a system with writeback support will someone ever be able
to create a sub-part?  I assume not.


Similarly, the following would not be appropriate
  .../sequence/Contig2

because there's always the chance of selecting a range from it
  .../sequence/Contig2/1000:2000


This is an ambiguity in the PUT spec as well.  Consider
one lock request section which specifies

          filter_href="feature?overlaps=Chr3/1000:500000"

and another which specifies

 POST http://dev.wormbase.org/das/genome/volvox/1/feature/?lock=xyzzy


My current belief is:
  - all of the namespaces ("sequence/", "region/", "feature/", ...)
     must end with a "/".  This means we will have URLs like
        .../region/ChrX/?format=das2xml
        .../feature/?type=exon

  - the assembly will not change for a given version so we
     specify that anything with a subregion must be referenced
     with a '/' and the server must redirect names that are
     missing the '/'.  Terminal regions must not end with a '/'.

  - Terminals (the actual feature, lock, etc.) must not end
      with a '/'.

The odd one out is the .../sequence/ namespace.  Is

  .../sequence/Contig1

ever allowed, given that clients may use
  .../sequence/Contig1/200:350

?

Note, btw, that sequence/ ranges are one of the few parts of the DAS spec
which is not REST-ful, because it violates the idea that URLs
are opaque to the client, excepting for '?' query parameters.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.