feat: patch/put on IRIs with custom ids. #5687
Conversation
|
I don't have a possible solution, but this comment is just to express my support for the discussion: it is a really important one in my opinion. |
|
can #5732 work for that kind of use cases as well ? |
I'm not sure, this problem is not about linking to other entities, but mostly about using put/patch on entities when their ORM id is not in uriVariables. Currently APIP tries to create a new entity instead of updating it. That being said it's somewhat related, my "solution" being to add some ORM specific metadata to specify which fields are ORM ids that shouldn't be updated. |
mrossard
force-pushed
the
customIri-patch
branch
from
bf4d9b7 to
8415cf0
Compare
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
just a note to remind myself to check this with 3.2 |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Still not giving this up, just not finding any time to work on APIP right now... |
|
I just fixed that I think #6019 |
Somewhat related to #5645
This is not really a PR, I'm mostly aiming to start a discussion on how to find a more "framework-wide" way to resolve such issues (even if this simplistic version does fix one use case).
I feel like the underlying problem i'm trying to tackle here is actually caused by an unclear differenciation between various close but not always related notions in APIP:
Those are often the "same thing" in a "standard" app (i.e. the id column of the entity is the api resource identifier and is used as is in the uri template), but that's not always what api deisgners want.
I think the framework would gain a lot of clarity at various places by keeping those notions separate and making them available all around. The IdentifiersExtractor comes close, but as you can see from this PR it doesn't handle some "complex" cases as it is right now.
Am I the only one feeling that way? And if not, what would a good way to do this be? A few months back while talking to @soyuka I mentioned I thought some kind of "State" object would make a lot of sense to replace uriVariables / some of the stuff that ends up in $context, I still think that could help building a "clean" solution.