I was wondering where the id was set, thanks :D

Thanks for pointing this out, I probably should have explained myself:

I'm hard coding 'GET' here to be consistent with the regular resource tree.
If you look at the `djblets.webapi.resources.WebAPIResource` class, in
`get_links()` you will see:

    for resource in resources:
        links[resource.name_plural] = {
            'method': 'GET',
            'href': '%s%s/' % (clean_base_href, resource.uri_name),
        }

`resources` is an argument (either list_child_resources, or
item_child_resources). So any child resources are always linked like this,
even when they don't have a 'GET' method.

At first this seemed like a bug to me, but I figure it's probably done
this way for a reason. the structure of the links in a resource go
like this:

    "links": {
        "self": { "method": "GET", "href": ... },
        "create": { "method": "POST", "href": ...},
        ...
        "child_resource_name": { "method": "GET", "href": ... },
        ...
    }

"self" always exists, and elements like "create" are there if the method
is supported. For each child resource, you only get one entry with the
resources name, and the method is always "GET", even if GET isn't
supported. Since we can only have a single method, it probably makes sense
to default it to "GET".

The only other option I can think of is to set some sort of priority, such
that the highest priority method supported is displayed. The problem with
this is you can't decide which methods a resource supports without some
extra knowledge not present in the tree.

Taking all that into consideration, I'd say a good way to deal with
resources is always have a "GET" method. This ensures the URL for
the resource will always return something meaningful when traversing the
tree, and you can discover exactly which methods are supported by looking
at the resource's links. Even if your resource won't return anything
meaningful, just use the default GET handler, and it will display the links
and an empty set for the resources data.

I hope this clears everything up, please let me know how you think I should
proceed with this.

I wonder what others out there do.

I'm not a huge fan of hard-coding GET, but it may be a necessary evil right now. We *should* be able to detect whether the resource supports GET, though, by looking at allowed_methods.

Perhaps we can check if GET is supported, and if not, change that link to be OPTIONS. No payload to fetch, but OPTIONS would give us the list of methods allowed.

I'm going to drop this for now, and take a look at fixing it in general sometime down the road.