# Spec for /articles/1/author URLs **URL:** \ **Category:** Uncategorized\ **Created:** [November 5, 2022, 1:36pm UTC](https://discuss.jsonapi.org/t/spec-for-articles-1-author-urls/2556 "2022-11-05T13:36:16Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![shpoont](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/shpoont/32/818_2.png) [@shpoont](https://discuss.jsonapi.org/u/shpoont)\ **Post date:** [November 5, 2022, 1:36pm UTC](https://discuss.jsonapi.org/t/spec-for-articles-1-author-urls/2556/1 "2022-11-05T13:36:17Z")
There is no dedicated section for URLs that look like `/articles/1/author`, but references to it are scattered around the spec. How this is used? ---
**Author:** ![fdrake](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/fdrake/32/654_2.png) [@fdrake](https://discuss.jsonapi.org/u/fdrake)\ **Post date:** [November 7, 2022, 3:42pm UTC](https://discuss.jsonapi.org/t/spec-for-articles-1-author-urls/2556/2 "2022-11-07T15:42:23Z")
The JSON:API specification does not cover URL structure, and it shouldn’t. Knowing appropriate “starter” URLs is left for the documentation of specific APIs. My understanding has been that this is intentional, and that seems like the best way to deal with the issue to me; it does not make sense to bake in assumptions about implementation strategy (such as a relational database) that might impact the URLs used. In all cases, an application can use the starter URLs documented for the API, and the URLs handed to it via the API. One approach I like for minimizing the set of specific starter URLs is to define an “api-root” type that includes attributes and relationship to any collections that an application would need; only the URL to the “api-root” resource would need to be specified in the documentation, and the remaining URLs can change or evolve as needed over the lifetime of the service. -Fred ---
**Author:** ![shpoont](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/shpoont/32/818_2.png) [@shpoont](https://discuss.jsonapi.org/u/shpoont)\ **Post date:** [November 8, 2022, 9:59pm UTC](https://discuss.jsonapi.org/t/spec-for-articles-1-author-urls/2556/3 "2022-11-08T21:59:52Z")
Hi @fdrake, My question is since the `/articles/1/author` is mentioned in the spec (along with other URL examples), what does it represent? The `/articles/1/relationships/author` endpoint represents `article`’s to-one relationship to `author`. Also, [Fetching Relationships](https://jsonapi.org/format/#fetching-relationships) explains pretty well the expected output of a relationships endpoint. But what is `/articles/1/author`? ---
**Author:** ![fdrake](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/fdrake/32/654_2.png) [@fdrake](https://discuss.jsonapi.org/u/fdrake)\ **Post date:** [November 9, 2022, 7:07pm UTC](https://discuss.jsonapi.org/t/spec-for-articles-1-author-urls/2556/4 "2022-11-09T19:07:02Z")
Okay, I think I understand what you’re asking now. I can explain this in the context of the example URL system used in the spec, but keep in mind that URLs should not generally be constructed in the client; it’s always best to use the URLs provided by the service. If the resource at `/articles/1` has an `author` relationship, that relationship’s `links` can contain two distinct URLs: - `self` is a link to the relationship itself, and in the example URL scheme, would be `/articles/1/relationships/author`, as you noted. - `related` is a link to the related resource. For a relationship that can’t be modified, it could be a “canonical” URL to the resource (e.g., `/people/2`), but for a relationship that can be modified, the URL needs to be specific to the `/articles/1` resource. So, `/articles/1/author` is the resource at the other end of the `author` relationship. Consider that you request `/articles/1` without `?include=author`; you might expect only to get the relationship structure: ```json {"data": { "type": "article", "id": "1", "relationships": { "author": { "type": "person", "id": "2", "links": { "related": "/articles/1/author", "self": "/articles/1/relationships/author" } }, ...}, }} ``` If another client changes the `author` relationship to refer to a different resource, using the `links.related` URL will return the resource _currently_ referenced by the updated `/articles/1`, which will not correlate to the resource identification originally returned with the resource. (Which suggests the resource identification data for a relationship probably should not be included if the resource is not also included in the response.) I hope this helps! -Fred ---
**Author:** ![shpoont](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/shpoont/32/818_2.png) [@shpoont](https://discuss.jsonapi.org/u/shpoont)\ **Post date:** [November 26, 2022, 8:30pm UTC](https://discuss.jsonapi.org/t/spec-for-articles-1-author-urls/2556/5 "2022-11-26T20:30:58Z")
@fdrake thank you for the explanation. It looks that while related resources in form of `/articles/1/author` could be useful in some cases, the spec has very small amount of information about them, especially what should happen if someone runs CRUD operations on such resources. ---
**Author:** ![fdrake](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/fdrake/32/654_2.png) [@fdrake](https://discuss.jsonapi.org/u/fdrake)\ **Post date:** [November 28, 2022, 5:44pm UTC](https://discuss.jsonapi.org/t/spec-for-articles-1-author-urls/2556/6 "2022-11-28T17:44:43Z")
I’m not sure what you think needs to be said. Those example URLs address resources, and CRUD operations against resources are described. Any limitations regarding CRUD operations on particular resources are in the domain of the application, and need not be associated with the URL used to access them. -Fred