Like anything else, there are the die-hard theorists who say never break the pattern. But that isn't a good enough reason to listen.
A good reason to do things "correctly" is that your tooling will expect you to do it correctly. End users, if it's a public API or even public inside your company, will expect you to do it correctly. If you do it in a non-standard way, it may cause you to have to write additional documentation, which is an expense.
You have to weigh out each situation. When making an API, I'd stick to the convention unless I had a particularly good reason not to. One example is the GET with a token for password reset. Just obviously be aware of the implications - e.g. query params expose data. Make sure it's not sensitive or short-lived.
And writing a prototype isn't a good enough reason to skip convention. Many a production app is still running its prototype code.
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.
Like anything else, there are the die-hard theorists who say never break the pattern. But that isn't a good enough reason to listen.
A good reason to do things "correctly" is that your tooling will expect you to do it correctly. End users, if it's a public API or even public inside your company, will expect you to do it correctly. If you do it in a non-standard way, it may cause you to have to write additional documentation, which is an expense.
You have to weigh out each situation. When making an API, I'd stick to the convention unless I had a particularly good reason not to. One example is the GET with a token for password reset. Just obviously be aware of the implications - e.g. query params expose data. Make sure it's not sensitive or short-lived.
And writing a prototype isn't a good enough reason to skip convention. Many a production app is still running its prototype code.