core: RFC: Filters do not respect the configured name converter.

Hey all,

Here’s an issue I discovered today. If your API has a configured name converter, (let’s say CamelCaseToSnakeCaseNameConverter), filtering on fields is unintuitive for the consumer.

Given an ApiResource with a field called createdAt, createdAt will be serialized/deserialized to/from the consumer as created_at.

However, if the consumer wants to then filter on createdAt, they must use ?createdAt..., which is very unintuitive as that is not how the field is represented.

The fix seems simple - make all filters respect the configured name converter. However, this would be a big BC break, so will need to go in 3.0?

Cheers

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 2
  • Comments: 15 (14 by maintainers)

Most upvoted comments

think this is done!

I would be in favor of fixing this. It looks totally unexpected on my side. If someone complains… we’ll provide a fix like a flag or something like that to restore the buggy behavior. WDYT?

Sorry to have opened a duplicate of this issue. I, for one, think of it as a bug since the client have to filter from what he knows : the response body. If the field is called created_at in the response body, then it must be created_at that will filter or sort a list of results.

I didn’t think a lot about the issue @Soullivaneuh , I just quickly update with the first (not best) idea I had to see if it would work… The discalmer was Quick and dirty 😉

Was it ever claimed that the filters would use the name converter? 😛

I don’t know if it could be considered a bug if it’s a missing feature…