Allow custom route names

[mwpastore]

Allow custom route names

[jgnagy]

This may be the solution to my problem, but is there no way to stop sinja from deciding where to put dashes in controller names (routes)? I have updated my test repo @ https://github.com/jgnagy/test-api (which happily works now thanks to #12 being resolved), but it takes the TestKey and forces the route to be /test-key. What if I didn't want a dash, and instead simply wanted /testkey? Is this configurable? If not, maybe this is something I could help with / submit a PR for.

[mwpastore]

Sinja draws the routes based on the symbol passed to the resource keyword. The symbol is dasherized and pluralized. Currently, there's no way to override this behavior, which is what this issue is intended to track. It's something I'm willing to prioritize if it helps an early adopter!

All that being said, your resource is named :keys, so the resource route should be /keys, not /test-keys. I think you may be looking at the links in the response payload. These are actually generated by JSONAPI::Serializers, and it is customizable! Just override the type method in your serializer class:

class TestKeySerializer
  include JSONAPI::Serializer

  attribute :name
  attribute :created_at

  def type
    'testkey'
  end
end

More information is available here.

This does create a bit of a problem because the links in the payload must line up with the routes drawn in the Sinja application (or else the consuming application may try to access a URL that doesn't exist on a subsequent request). You can kinda-sorta "customize" the Sinja routes by passing in a different symbol, for example resource :testkey (/testkeys) instead of resource :test_key (/test-keys). Unfortunately, as I described above, there's currently no way to get /testkey due to the pluralization rule.

[jgnagy]

Yes, that helped quite a bit for test scenario (I committed my update to reflect that), but unfortunately I think it needs to be done at a deeper level in sinja because it is failing in my application while including a related has_many resource. In my real use-case, I have GET /users/1?include=apikeys%2Cidentities (bringing along both apikeys and identities), but the response payload doesn't seem to rely on the underlying APIKey's type instance method when creating the has_many collection.

I am trying to build an app that relies on your library to implement the {json:api} spec, so I don't know if that makes me an early adopter, but I would certainly appreciate this customization being available. I can successfully POST to /apikeys and create a new key, but subsequently listing a user's keys produces unexpected results. Going from dashes to underscores in a consistent manner across libraries and possible languages is difficult, so being able to explicitly dictate the route would be helpful.

[mwpastore]

Nothing you've described makes me think you need this feature. Do you have some time to chat with me on Gitter or somewhere else so I can help you work through this use case?