Custom resource name is not being honoured /RFC

Issue

Currently when you add a Resource(..) attribute to a resource in the DbContext as such:

[Resource("weird-NaMiNg")]
public virtual DbSet<SuperNiceModel> SuperNiceModels { get; set; }

The name SuperNiceModels (the property name) is being used to create an URL and type identifier. The following identifier is used because of that: superNiceModels. What is the weird-NaMiNg identifier actually being used for?

Solutions

Two way to approach this:

First Version

If i add a Resource("cookiesMcCookieFace") To a mobel in my DbContext, I expect two things:

• An overridden url /api/v1/cookiesMcCookieFace
• An overriden type {'type' : 'cookiesMcCookieFace'}.

Second Version

If i add a Resource(url: 'cookiesMcCookieFace', type: 'cookie') To a mobel in my DbContext, I expect two things:

• An overridden url /api/v1/cookiesMcCookieFace
• An overriden type {'type' : 'cookie'}.

Thoughts?

[maurei]

With respect to the urlIdentifier part of the approach, I’ve been giving it a second thought. In JADNC v3.1 the url part was generated based on the controller:

// would expose the FooBar model as `{namespace}/foo-bar` 
public class FooBarController : JsonApiController<FooBar> { } 

// would expose the FooBar model as `{namespace}/custom-bar-foo` 
public class CustomBarFooController : JsonApiController<FooBar> { } 

Note that this is just a .NET Core off-the-shelve feature. The only thing that JADNC did was to apply a casing convention (.net cores default PascalCase to kebab-case). (Also note that ResourceAttribute never affected the url part in v3.1)

What happened in v4 is that the link between controller/url and associated link was registered internally so that we could populate the CurrentRequest service in the middleware rather than in the controller layer. I think an unwanted change there is that the calculation of URL changed: it moved from controller-based to model-based, i.e. CustomBarFooController now maps to /{namespace}/foo-bar. This is what brought about the unexpected routing changes in your projects. (And of course, also kebab-case was changed to camelCase).

I would be in favour of reverting this change and generate the URL based on the controller again to fix the issue your faced:

• This way we would not introduce a breaking change and we would still mostly rely on off-the-shelve .net core routing instead
• Still, we could still implement solution 2 as a feature to completely override the url identifier with a custom bit, which one could use if you wish to deviate from eg the casing convention.

[maurei]

Superseded by #786 and the associated PR. Decisions about this topic have been made there. More info about the current approach is described here