And I would respond to GET and simulate POST/PUT/DELETE in memory. While I was working on the backend proper, my teammate could just assume that the backend was 'working'. Then when I was ready, I wired in the real implementation.
The advantages I found of doing this server side instead of client side (like in the article) was that the network round-trips were real, thus we'd know when there was something too inefficient going on. Plus, we would work on the same domain objects (captured in the JSON) so there was no hurdle when I wired the real implementation. Finally, I used the JSON files to stub some fake data into the database when we wanted to test it out.
Ideally, I think something like this is good, but for prototyping, I think $httpBackend is a good solution. I'm on a mid-sized project currently where I implemented a mock backend with $httpBackend, and use a fetch node script to pull all of the json we want from our daily build for development locally. When we need to compile our assets and prepare it for deploys for testing on the daily server, we have a nice grunt script to do that and test things out on the daily build.
When a frontend dev is rapidly building out features though, he/she shouldn't be concerned with the performance of the backend - having a full stack dev server to accompany a mock backend for local development or some sort of local solution is ideal.
The advantages I found of doing this server side instead of client side (like in the article) was that the network round-trips were real, thus we'd know when there was something too inefficient going on. Plus, we would work on the same domain objects (captured in the JSON) so there was no hurdle when I wired the real implementation. Finally, I used the JSON files to stub some fake data into the database when we wanted to test it out.