@Laiv yup, the number of links can obviously grow, and I can appreciate that, but to an extent I know that in the near future, the business will not require that many more links. Yes, may be stackoverflow, youtube, or whatever, sure, but the business intent here is not to cover all the possibilities. So your comment on over-engineering is relevant here.

Exactly what my doubt was that prompted me to ask this question. The only relation between the different links is that they would possibly be displayed together in the UI. So, in this case, you would suggest NOT to put them into a separate object right, but rather keep them directly under the User object?

I completely agree that in the future, I might want to add more options than just Facebook, Instagram, and Twitter. But it will always be a limited number of possibilities from the user's perspective. Unlike, say, a "Photos" collection where a user can add n number of photos (a dynamic, unknown number of photos), so a List is obviously the choice there. But in my case, the total number of possibilities will always be defined by me (3 links today, may be 10 tomorrow), the only expectation from the user is to fill out the value (the URL) of the item. Do you still think it needs to be a List?

Thanks @Troy. As for the nested resource path, one reason I decided to do it that way was, down the line sometime, I might introduce usernames, and so the endpoint would become /<username>/games, which would be quite intuitive to understand. Would you still avoid the nested resources approach?