URL not constructed in PUT/PATCH methods

[thinkwelltwd]

Thanks for the rest_framework and the core-api library. It's exactly what I need; but I'm pretty sure I've bumped into a core-api bug. Wrote up this stackoverflow post about it.

Would be most grateful to figure out a way through this.

[ghost]

Hello, I have a strong proof that is related to following line in http transport:

field_map = {field.name: field for field in fields}

This only filters unique keys instead of path + parameter. So if path and parameters are same, it will take one randomly. I had similar behavior between my different models. @tomchristie

[crgwbr]

Any updates on this? I'm being hit by the same issue. Can #138 be merged and released anytime soon?

[thinkwelltwd]

A polite tap-tap, @tomchristie. Would it be possible to get your eyeballs on this issue, and perhaps merge #138?

[tomchristie]

Okay, so if anything we should be erroring if there are two parameters with the same name. (rather than forcing the path one to take precedence) Perhaps REST framework's schema generation needs a fix here? Shouldn't cid be read-only in the serializer, and would that fix the issue?

[thinkwelltwd]

Shouldn't cid be read-only in the serializer, and would that fix the issue?

I suppose partly, but when creating a new record, the cid field must be writable. Updating can be read-only. The cid field shouldn't be changed after creation. (Perhaps I should have named the field guid which would've been a more standard abbreviation. cid = Canonical ID)

FWIW, I'm also using AllowPUTAsCreateMixin.

[ryanolf]

There is a related issue when query parameters and form parameters have the same name, which might happen if one has a resource where the query parameters filter on fields of the object. In this case it seems natural to have two parameters with the same name.

One solution for _get_params() might be to loop through the fields and populate values from the params, where available, and then to deal with the parameters that didn't match to any fields. This would allow matching a param to multiple fields. Currently _get_params() loops through params and matches to just one field.

[smn-snkl]

Any update on this? Running into the same issue as @ryanolf described above. Having a query and form parameter with the same name leads to dropping the query parameter.

[thinkwelltwd]

Per @tomchristie, this project is dead. I wish he'd communicate better about it.

[tomchristie]

Personally I'm not making further changes to the project, since my focus is elsewhere.
It's not dead, it's just I'm not putting more work into it from its current state.

Having a query and form parameter with the same name leads to dropping the query parameter.

Probably don't do that.

[thinkwelltwd]

It's not dead,

Current functionality will continue to work, yes.

it's just I'm not putting more work into it from its current state.

A project where the owner makes no more changes and accepts no more PRs is dead.

Thank you for the project, @tomchristie. The point I'm trying to raise is that it's not at all easy to discern that the project is no longer the focus of your energies and that you've moved to on to focus on other projects. I have no quarrel with that.

I'm only trying to raise awareness to other developers who rely on this project, as I once did, that they shouldn't expect changes.

Again, I would ask that you announce the project's status on the Read Me. Whether you call it deprecated, dead or EOL, I don't care. But let folks know in a prominent location.

[smn-snkl]

Thanks for bringing this up! And thanks @tomchristie for all the good work, really enjoyed this. Is there a good alternative project you can recommend?

[tomchristie]

API Star is the evolution of this project: https://github.com/encode/apistar

The client library http://docs.apistar.com/client-library/ is OpenAPI driven, which is what's become the standard.