Two thoughts on this. If you're going to do this, how about just using a delete endpoint and if a confirmation key isn't passed, you send back the message and a confirmation key, that way keeping the logic within a single endpoint.
Other thought though, is that this is properly the responsibility of the frontend. The api should assume an authorised client is doing what they want to to do. Otherwise, you might also want a confirmation on update, because that is deleting data as well. With frontend components, adding a confirmation dialog isn't laborious, can be done cleanly, and keeps your CRUD in line with standards.
Thanks for your opinions. Here are some thoughts. edit and create aren't apart of API standards, so we are talking about slightly different things. The store endpoint doesn't have an inputs key to avoid a create endpoint and its main responsibility is returning a view / frontend. When presenting validation errors.. we do so on create and edit, so presenting a password mismatch error wouldn't make sense on destroy. It is common to have a password confirmation for destructive actions.. Amazon, Github, many apps do it. I do think this more closely matches the CRUD standards hence the presenting of my opinion :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Two thoughts on this. If you're going to do this, how about just using a delete endpoint and if a confirmation key isn't passed, you send back the message and a confirmation key, that way keeping the logic within a single endpoint.
Other thought though, is that this is properly the responsibility of the frontend. The api should assume an authorised client is doing what they want to to do. Otherwise, you might also want a confirmation on update, because that is deleting data as well. With frontend components, adding a confirmation dialog isn't laborious, can be done cleanly, and keeps your CRUD in line with standards.
Thanks for your opinions. Here are some thoughts.
editandcreatearen't apart of API standards, so we are talking about slightly different things. Thestoreendpoint doesn't have aninputskey to avoid acreateendpoint and its main responsibility is returning a view / frontend. When presenting validation errors.. we do so oncreateandedit, so presenting a password mismatch error wouldn't make sense ondestroy. It is common to have a password confirmation for destructive actions.. Amazon, Github, many apps do it. I do think this more closely matches the CRUD standards hence the presenting of my opinion :)