-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support 409 for PATCH requests. #312
Comments
Thanks, that looks like a missing feature. For make this go into liberator's code base we need tests and docs, too. Please tell me if you want to have a take on it. |
Yes, I would be glad to. Is it ok if I prepare a pull request with also test and docs? |
@elenacanovi Sure! I would love that. |
Hi guys, was there ever any follow up on this issue? |
Not from my side, sorry. I'm currently not working on that. |
@casseds2 I'll try to find the time to merge it. As writren above this requires updates to the documentation and tests which takes some sime. |
Thank you very much Philipp! You're help is greatly appreciated 👌 🙂 |
As per the RFC specification (https://tools.ietf.org/html/rfc5789#section-2.2),
PATCH
requests should be able to return 409 in the cases of conflicting state or concurrent modification (my use case btw). However, if I understand correctly the decision graph, this possibility is currently not supported by Liberator ifmethod-patch?
istrue
.As a possible solution, I tried to add a new decision called
patch-to-existing?
to replacemethod-patch?
in thefalse
branch ofmethod-delete?
and movedmethod-patch?
to thefalse
branch ofconflict?
. Ifmethod-patch?
is true then the path leads topatch!
, otherwise it leads tomethod-post?
from where the old behaviour is recovered.I committed this variant to my fork here: elenacanovi@87dc3e5.
The text was updated successfully, but these errors were encountered: