Member Nodes

minor variations of known identifiers are returning content instead of NotFound exception.

There are 2 or 3 parts to it:

1. multiple consecutive slashes in the identifier are treated as one. So http:/dx.doi.org/foo and http://///dx.doi.org/////foo will return the same thing.
   
   In some cases, the identifier uses http:/dx.doi.org, in other cases http://dx.doi.org. (http://datadryad.org/mn/v1/object/http:%2Fdx.doi.org%2F10.5061%2Fdryad.8665)

2. the resource-map-indicator-suffix "?format=d1rem" will return a resource map, but so will "?format=d1remarkable" or "?format=d1remfooooooooooooo". The /object call returns a resource map with the "official" resource map identifier, but the /meta call uses the identifier from the api call as the identifier.

3. altering the "ver={date} suffix to the resource map indicator generates a unique variant of the resource map, incorporating that identifier into the RDF.
   So for example, the identifiers:

http:/dx.doi.org/F10.5061/dryad.12?format=d1rem&ver=2011-08-02T16:00:05.530-0400foobar
http:/dx.doi.org/F10.5061/dryad.12?format=d1rem&ver=2011-08-02T16:00:05.530-0411
http:/dx.doi.org/F10.5061/dryad.12?format=d1rem&ver=2011-08-02T16:00:05.530-0412
http:/dx.doi.org/F10.5061/dryad.12?format=d1rem&beer=2011-08-02T16:00:05.530-0400

all return different resource maps (with different checksums and potentially sizes) that aggregate and document the same metadata and data objects related to the DOI. The differences reside in the URIs of the resource map and aggregation elements.

The main point is that it's also important for the rest endpoints to return NotFound when the identifier requested doesn't exactly equal a known identifier.

I'm not sure how that affects how you provision resource maps dynamically, but I assume that you keep track of resource map identifiers that are put into listObjects? maybe a check against that list before evaluating any regex's would do the trick.