We have a model in the backend that we refer to as a different name in our public API. We need to override the type returned but haven't found a way to do this yet.
I tried adding def self._type (as I noticed that's where it was grabbing type from) to my base model class as well as the resource serializer but that didn't change the response.
Any help would be appreciated.
https://github.com/cerebris/jsonapi-resources#model-name should do it
Thanks. I tried that and it didn't work. Here's the setup:
project table
project.rb defining Project class
ProjectsController
ProjectResource
I need the type in the json responses for projects to be 'study'.
# still returns type as 'project'
class Api::V2::ProjectResource < JSONAPI::Resource
model_name 'Study', add_model_hint: false
end
I was able to make it work by changing resource and controller name to the public API name, and using model name to point the public-named resource to the correct backend model.
Not sure if this is a good solution since it's not conventional Rails where the controller name be the same as the model name.
In JR the convention is for the controller to match the resource name. The resource acts as an intermediate layer mapping to the model so the naming disparity is expected.
Alright cool. Thanks @thibaudgg !
@bpourriahi not sure why, but you're welcome anyway! :smile:
Heh. That may or may not been a 'typo'. Thank you @lgebhardt.
@lgebhardt I'm using namespaced STI and I think JR type convention doesn't match this use case.
As explained in http://jsonapi.org/format/#document-resource-objects:
The type member is used to describe resource objects that share common attributes and relationships.
I'm working on an infrastructure management app that includes a lot of models that are namespaced to avoid any collision. For example, my model DNS::Zone will be typed as zones by JR. But I could have another kind of zone in the future.
IMHO, JR type should actually match the URL namespace, which in my case is dns/zones.
This is a little different with namespaced STI like my CDN::Purge which is declined to CDN::Purge::Custom, CDN::Purge::Full and CDN::Purge::Collection that are respectively typed customs, fulls and collections which have no sense.
My first thought was to rename my models like CDN::Purge::CustomPurge, which would be typed custom_purges.
This would be fine except that the cdn namespace is still missing, and that my controller and route are still purges.
That means that the type should actually not match the controller name, but the model name, given the resource attributes could vary in the same controller. In that case, I wouldn't have to rename my models as I don't hink JR should impose a model naming convention.
In any case, the type field should be customizable, even if convention is always better.
Is this something which is being considered? I've tried the workarounds above and had no luck.
We are in a similar situation where we have multiple services which might share resource names (e.g. AssetFile) which will be different across the services. Ideally we want to namespace the types to match the URL namespace e.g. something like this:
model_name "ExampleServiceName::AssetFile"
def type
"example_service_name/asset_files"
end
Even better would be if we can define the prefix globally across each app by defining this in a base class, or ideally have JR pick the namespacing up from the namespaced model_name in the above example.
I'm also trying to figure this out.
I have STI models Events::Applied, Events::Interview which inherit from base model Event. I'd like to use a common controller/endpoint api/v1/events but have the type as events/applieds or events/interview (similar model names to @gauthier-delacroix which leads to weird pluralization ("applieds"). In hindsight I'd have named the models Events::AppliedEvent etc. but I don't think that actually affects this.
Namespaced type is important to me since my frontend Ember app has a similar folder structure with Event subclasses under an events directory. With a type of events/applied, the Ember resolver will look under models/events/applied.js rather than models/applied.js
Did this by using jsonapi-utils by explicitly defining the actions in the controllers so you know exactly whats going on.
# Specify a particular HTTP status code
jsonapi_render json: new_user, status: :created
# Forcing a different resource
jsonapi_render json: User.all, options: { resource: V2::UserResource }
# Using a specific count
jsonapi_render json: User.some_weird_scope, options: { count: User.some_weird_scope_count }
# Hash rendering
jsonapi_render json: { data: { id: 1, first_name: 'Tiago' } }, options: { model: User }
# Collection of Hashes rendering
jsonapi_render json: { data: [{ id: 1, first_name: 'Tiago' }, { id: 2, first_name: 'Doug' }] }, options: { model: User }
Most helpful comment
@lgebhardt I'm using namespaced STI and I think JR type convention doesn't match this use case.
As explained in http://jsonapi.org/format/#document-resource-objects:
I'm working on an infrastructure management app that includes a lot of models that are namespaced to avoid any collision. For example, my model
DNS::Zonewill be typed aszonesby JR. But I could have another kind of zone in the future.IMHO, JR type should actually match the URL namespace, which in my case is
dns/zones.This is a little different with namespaced STI like my
CDN::Purgewhich is declined toCDN::Purge::Custom,CDN::Purge::FullandCDN::Purge::Collectionthat are respectively typedcustoms,fullsandcollectionswhich have no sense.My first thought was to rename my models like
CDN::Purge::CustomPurge, which would be typedcustom_purges.This would be fine except that the
cdnnamespace is still missing, and that my controller and route are stillpurges.That means that the type should actually not match the controller name, but the model name, given the resource attributes could vary in the same controller. In that case, I wouldn't have to rename my models as I don't hink JR should impose a model naming convention.
In any case, the type field should be customizable, even if convention is always better.