> For the last few months I've been learning back Django which was my first love. I'm learning back the django rest framework and today I have an issue where in the DRF interface the button for POST/DELETE/PUT/PATCH don't work. They don't even send the POST/DELETE/PUT/PATCH request, they just reload the page as if the only thing those button do where `window.location.reload();`.<p>It's hard to know for sure without actually seeing it, but...<p>This sounds very much like a fairly typical JavaScript problem. Or to be more precise, a "lack of JavaScript" problem. Let me first explain what I think may be the problem and then <i>how you could look into solving it</i>.<p>The problem as described makes me think:<p>- There is a button which submits a form. It <i>should</i> use an XHR for the submission, which means there should be some JS event handler attached to the button.<p>- But instead of that, <i>if for whatever reason the handler was not attached correctly</i>, then the button would simply submit the form it belongs to in a default way, which would reload the page. This fits the description you give.<p>So, first thing, how can someone go about verifying if this is indeed the case of what is happening?<p>What you do is you open your browser development tools and look around for a couple of things. First, you load the page normally, and do not <i>yet</i> click the button. Now, you look in the console for any JS errors at all and, if there are any, see if one of them maybe either a. related in any way to the button, the form, the event handlers, etc, or b. there is one that <i>breaks JS execution</i>, which would prevent other code from being run. More: You inspect the button itself with the DOM inspector and verify if it actually has any click event handlers attached. Note that it may be the case that the handler is attached as a submit handler on the form, instead of as a click handler on the button. If there is <i>neither</i> of those, then it's very likely that something has prevented some piece of JS from being run and the handlers from being attached.<p>After looking at that, still with your browser dev tools open, you set the network tab as visible, and then actually click the button and trace what happens. There's a lot to learn about browser dev tools, and there is a lot of info out there, so when you have a chance, that's something you could spend some time on. But right now you just want to check the request that happens when you click the button. In particular you need to look at the type of request and the "initiator". These will tell you whether it is indeed a "normal form submission" or an "XHR request".<p>Once you verify these things, if this is not the problem, then you'll need to explore other options -which I cannot specify more due to the lack of information, of course-.<p>But if this is indeed the problem, that there's no event handler attached and the form is simply submitted, then you need to investigate why there is no handler attached, obviously.<p>Again, try to search for any errors in the console, check id's used on the form or button, check the template that generates the button and form. Also check the network template for any 4xx, 5xx, or any files that are not loading for whatever reason. It may be a misconfigured path, a missing library, a misconfigured MIME type... It can be a lot of things.<p>If you can't find anything like this that gives you a clue, then it's time to change the approach. Now start by looking for the origin of that button in the source. Where is it created? How is it created? Does it depend on any parameters? Are those correct? Does it depend on a <i>global</i> configuration? Is that correctly set up?<p>I can't tell you anything more specific than this, but that is how you "go about solving the problem". At some point, you'll most likely find a misconfigured path, or a missing file or parameter. Or, at the very least, you'll find an error message that can give you a clue of what is happening and what should be your next step. With that it will be much easier to ask questions.<p>----<p>So, in summary, you fight the powerlessness by actually trying to figure it out. There is no secret, really. There's no magic thing people do to solve problems we haven't seen before.<p>Note, also, that I cheated a bit. That is, going from your description I offered an experience I have previously had. But what if it was my first time? What if I had never seen this? The idea, then, is to first establish what is actually happening. You suggest "...as if the only thing those button do where `window.location.reload();`". This is an hypothesis. So you verify it. You do the thing with the browser dev tools -which you learn to use beforehand, of course-, and try to verify if your hypothesis is correct.<p>There's a small catch, though. Your hypothesis there is a bit "too sophisticated". Why would someone attach some JS to do location.reload()? Could there be an easier explanation? That's where the above comes into place: if you attache no handler at all, the submission is just a normal form submission; if the form has no explicit action declared, it will POST/GET to the same current URL.<p>So, in a way, that <i>is</i> a small secret -but really, it's not secret- thing: always start verifying from the <i>simplest</i> things. Always check the most simple hypothesis. This can even be extensible to "always check the most visible/obvious things", like always checking the error console and always giving the network tab in the dev tools a look for 4xxs or 5xxs.<p>Also, as already mentioned: owning the code. But this does not necessarily mean making the calls. Sure, you did not make the decision to use DRF, ok. But you can still make the effort to learn DRF to a desirable extent.