We should remove this special case, I can pick up if you want @rachelbaker

@joehoyle thank you, please do.

Is there going to be some alignment on "tag" (rest_base) vs "post_tag" (slug)? I get that "post_tag" is "ugly," but who really cares? The API should be data-driven, and not make special cases for personal preferences. The more the API special-cases "tag", the less consistent it becomes. Please, I beg you, use $tax->slug everywhere.

@jdolan this issue is about using the rest base, so your concern is not specifically here. However, as far as the API exposes data, you'll only ever see tag, not a mix - so I don't know why it's a big issue. Tags are not just for posts, so the name is confusing, that's my 2c anyway. This change just fixes one small inconsistency where we didn't use rest_base (where we always should be doing).

It's an issue because rest_base is never exposed to the client. Nowhere in the JSON response for the taxonomy object does it include rest_base. It does, however, include the slug -- and slug is precisely what should be used to map to URIs. That's what slug is for. See #1381.

@jdolan #1381 still stands, that's not about what this fix was for. This is about using rest_base to build the url. If #1381 means we set rest_base to be post_tag then fine. This code is right either way.

I realize that. I just see more special casing to accommodate the rest_base mistake seeping into the code and it makes me cringe. This code doesn't even use rest_base from a constant or some other variable -- it just replicates it. If I'm a jerk for pointing this out, then I apologize.

@jdolan rest_base is not about post_tag we have to support it for custom taxonomies too. If anything, this commit supports you argument, it is getting rid of special casing the case.