URI of REST to reflect relationship of resources?

1
votes

I knew some name conversions of REST API, for example resource name should be plural, using different HTTP method with same URI to perform different action on that resource, etc.

But as URI should reflect relationship of resources, I am a little confused. Take SO as a example, when update a existed comment of a answer, URI should looks like:

PUT /{contextPath}/questions/{questionId}/answers/{answerId}/comments/{commentId}

But I feel awkward when using this so-called standard URI because:

  1. It's a little verbose, especially when the hierarchical is very deep.
  2. questionId and answerId is completely unnecessary here, since commentId is sufficient for server to identify a comment record.

So what's the appropriate way to deal with this? should I always follow name conversions, or make some changes when the relationship hierarchical of resources is very deep?

3
resturlurirestful-url

3 Answers

2
votes

I emphatically disagree that "URI should reflect relationship of resources".

URIs are pointers to resources. That's it. There are conventions for making them human-readable, and therefore easier to work with. There is certainly no hard-and-fast rule that relationships should be modeled on the URI path. Feel free to model resources in a flat, rather than hierarchical manner. Use links to model relationships between the resources, and query parameters to narrow down collections.

1
votes

It gives you more Options without haveing to make extra requests.

Thus allowing you to call functions that might require say a questionId. When you only have the commentId you have to first query your questionId.

Depending on what your functions require. If you had specific info on the previous page and have to use it again in the next why query it twice? Unless it is sensitive which an questionId clearly is not.

Thats my opinion on how you should look at your addoption of the standard

1
votes

I would simplify the route/URI to:

 PUT /comments/{commentId}

along with at the corresponding RequestBody, perhaps some sort of DTO. The URI should not have to show the hierarchy all the way from the context path. It can be the shortest URI that can uniquely identify the resource