When I first started learning PHP (about 5 or 6 years ago) I learned about Ajax, and I went through "the phases":
- Your server returns HTML data and you put it inside a DOM's innerHTML
- You learn about data transfer formats such as XML (and say "oooh so THAT'S what it's used for) and then JSON.
- You move to jQuery
- You learn about APIs, headers, HTTP status codes, REST, CORS and Bootstrap
- You learn SPA, and frontend frameworks (React, Vue.js, and AngularJS) and the JSON API standard.
- You receive some enterprise legacy code and upon inspecting it, find that they do what's described in step 1.
As I worked with this legacy codebase, I didn't even consider that it could return HTML (I mean, we're professionals now, right?), so I had a hard time looking for the JSON endpoint that was returning the data that the Ajax calls populate. It was not until I asked "the programmer" that he told me it was returning HTML and being appended directly to the DOM with innerHTML.
Of course, this was hard to accept. I started thinking of ways to refactor this into JSON endpoints, thinking about unit testing the endpoints and so on. However, this codebase has no tests. Not a single one. And it's over 200k lines. Of course one of my tasks includes proposing approaches for testing the whole thing, but at the moment we're not tackling that yet.
So I'm nowhere, in a corner, wondering: if we have no tests whatsoever, so we have no particular reason to create this JSON endpoint (since it's not "reusable": it literally returns data that only fits on that part of the application, but I think this was already implied since it... returns HTML data).
What exactly is wrong with doing this?