Should we commit to `wp/v2/taxonomies/post_tag` or switch to `wp/v2/taxonomies/tag` ?

[danielbachhuber]

Given we've intentionally gone with wp/v2/tags, should we transform the post_tag slug to tag in the REST API?

[kadamwhite]

I can see arguments for both cases, but given the pains we've taken to standardize naming within the API already, I feel the most internally-consistent option would be to use "tag".

[Braad]

+1 for standardizing on "tag"

[rachelbaker]

@rmccue @joehoyle This needs a decision for 4.7.

[jnylen0]

Another option would be to use each taxonomy's rest_base here.

• post_tag → tags
• category → categories

This is more consistent with the rest of the API in both removing the post_ prefix and in pluralizing tags and categories in most places where they appear.

[jorbin]

I like @jnylen0's idea. Let's do it unless someone has a better argument they want to make.

[danielbachhuber]

Meant to comment yesterday but not sure where that went. Historically, rest_base was intended for the base route of resources, and singular slugs for identifiers. Posts are /wp/v2/types/post, not /wp/v2/types/posts.

[jnylen0]

If we make a change other than post_tag → tag here, we should do the same change for /wp/v2/types also.

I like the consistency of using rest_base everywhere, but I agree it looks a bit strange to have wp/v2/taxonomies/tags.

If we don't switch to rest_base, then we should add rest_base as a response property on both the taxonomy and post type items. Currently there's not a way to programmatically link the taxonomy parameters to the term endpoints or the post type items to the corresponding post endpoints.

[jnylen0]

We should add rest_base as a response property

We should probably do this regardless of the decision made here. @youknowriad has a patch up at #38607.

[rachelbaker]

Accept the rest_base as the item path parameter for Taxonomies and Types controllers

[rachelbaker]

In 38439.1.diff​ I have a proof of concept for how we can change the item routes for the taxonomies and types controllers to look-up the resources by the rest_base value. This still needs unit tests and testing.

The attached patch would still allow tags to be accessible from their rest_base taxonomies/tags OR the taxonomy name taxonomies/post_tag. This is the part that I don't like... if we were to do this we likely want to return an error if the taxonomy name is used, but a rest_base is set and does not match.

Thoughts @rmccue @joehoyle @jnylen0 @danielbachhuber ?

[danielbachhuber]

I'm -1 on using rest_base as the slug for taxonomy or post type entities. The original intent of rest_base was to use it as the 'base' for routes, not as an identifier for the resource.

I'm still +1 on changing post_tag to tag, because I think post_tag is an anachronism we can move beyond.

[rachelbaker]

I am -1 on having special case handling for just tag. I agree post_tag is ugly, but I don't want to make a special case for it either.

[joehoyle]

I'm also -1 on special casing post_tag, that's the taxonomy name - and I think that's what we should stick with. The decision was taken to name the taxonomy that way, so I think it's simpler and more consistent all around if that's it.

[danielbachhuber]

Long live post_tag, forever throughout the universe.