You should not change expected behaviour of REST API anymore.
Anywise, that is not REST API, it's your own REST-BASED API. then you should explain that on description

Okay well I still stand my ground, I understand what you are saying about the validation of the "empty" object but take this kata for example, what happens if I pass an object to the function? Or garbage strings? Or a string with special characters? Would you say it's an error in the kata's design? Nop, because it escapes the kata's intention, and the author addresses this problem by explicitly putting in the description (in the notes section) that those scenarios will not be tested, and there are many katas like this so I don't really understand why this kata has to be the exception, it's not that I'm ignoring what could happen with "invalid" objects it's just that it escapes the kata's intention, and I'm making it clear in the description.

I think the whole problem is because the "REST API" title (and if that's the real issue I would gladly change it), my original intention was to use some of the concepts of what a REST API is and put together a fun challenge, I even said in the description the goal was to mimic the behaviour of what a backend framework do when it needs to handle an incoming request (hence the name of the method "dispatch"). There are plenty of katas with made up scenarios whose pure ultimate goal is make the dev come up with a solution to a fun problem or challenge and practice some of their coding skills, like this one, this one or this one. I intended my kata to be one of those fun challenges and I can see that at least 55 people had fun trying to solve it.

I call an "empty object" an object that has no properties, I was confident the description of the kata could provide enough context to know what it was referring to

This is not a problem of the description, it's a problem of the kata design: You're passing in an object that has a different data structure from the actual dataset, and expect it to be rejected. Checking null is automatic; checking object properties conform to a unknown schema is not, and in fact, logically impossible since the expected result is unknown.

Kata design problems aren't supposed to be shoved away as "description problems": you're not going to fix this by just saying more things in the description. The kata needs rework.

please keep in mind that this is my abstraction on this particular problem that is building an API

Then why do you call it a "REST API"? If it's supposed to be a REST API (which is confirmed by the kata title and the entire description) then it should behave like a REST API; instead now we have a thing that claims it's REST API but is actually designed like something else (I'd say a service that operates on a database table). It's not what a REST API looks like at all. Please note that approved katas are actually intended for others to solve and learn: having an approved kata like this is misleading to users at best.

Besides, it's still a bad abstraction (which reasons I've described). Why do you insist on making others endure bad abstractions?

The kata says that if an object's property matches with the value of the query passed then it should be returned, I thought that part was self-explanatory since we are talking about basic primitive types such as numbers and strings, however if this is a problem how could I make it more clear in the description?

Again, not a description problem. The kata is not designed/described in any way that the data set is restricted to only one type of data; and the data only contains 3 fields (1 number and 2 string fields) so claiming "we are talking about basic primitive types such as numbers and strings" is already blatantly false since nothing else other than numbers/strings is tested. And not all languages are JS, so comparing different types directly without specifying how is a no-no.

The kata always make PUT request based on the id property, which the kata says is unique for each person, so it does not affect multiple objects

And now for the thing you really should put in the description you're assuming it's not a problem. Why?

The DELETE request does in fact remove multiple objects but because I thought of it more like "delete all where..." kind of deal, in that sense you are rigth it differs from typical DELETE request where you usually delete objects given an ID, but then again this kata is my particular abstraction on this problem

Again, then you should stop calling it a REST API. You made no descriptions that your idea of DELETE is one that differs from all common conventions (which either only deletes one object, or deletes the whole collection), and it's not described anywhere. And then you blame people for assuming wrong by going for the convention? We're not supposed to read your mind.

it seems unfair to me to get this kata back in the "beta" state

No. In fact it's obvious that this kata has been approved prematurely.

Hi there! First of all thank you for taking the time to review this kata, I will address your concerns here to avoid replying multiple times

1. I call an "empty object" an object that has no properties, I was confident the description of the kata could provide enough context to know what it was referring to. If this is a problem then how could I make it more clear in the description?

2. While I understand your annoyance towards how this kata handles the GET/DELETE requests receiving objects when in reality this is discouraged please keep in mind that this is my abstraction on this particular problem that is building an API. There could be thousands of different versions of this kata but the one that I found was easier for me to implement was simple passing a "request" object indicating the HTTP method it needed.

3. The kata says that if an object's property matches with the value of the query passed then it should be returned, I thought that part was self-explanatory since we are talking about basic primitive types such as numbers and strings, however if this is a problem how could I make it more clear in the description?

4. The kata always make PUT request based on the id property, which the kata says is unique for each person, so it does not affect multiple objects. The DELETE request does in fact remove multiple objects but because I thought of it more like "delete all where..." kind of deal, in that sense you are rigth it differs from typical DELETE request where you usually delete objects given an ID, but then again this kata is my particular abstraction on this problem.

I want to finish this reply by saying that it seems unfair to me to get this kata back in the "beta" state since there is nothing wrong with the kata itself, the description is not misleading as is describes exactly what you need to do in order to solve it. I sincerely hope this kata gets published again soon.

For the record: The kata was moved back to beta per mods request due to issues reported shortly after approval.

Why can PUT and DELETE affect multiple objects? This is massively frowned upon in typical REST conventions.

Query string is always stringly typed, but the objects can have types other than strings (such as id). It is not specified how filtering should handle values of different types.

The design of this kata inflates the notion of an object with no properties and a missing object. What exactly does "an empty object" (as the kata calls it) mean? {} is also a valid object, so there must be another criteria to determine what is empty. Meanwhile, this payload makes no sense whatsoever as it means you're passing in invalid objects as the body (instead of not passing in objects), and GET/DELETE can't ever have request body so payload shouldn't even be an object. This design doesn't make sense.

Beta Status:Awaiting approval

Can a moderator approve this kata, please?

See my issue above: using assertDeepEqual forbid solution wich doesn't preserve initial (and next update) order of data... this could be fixed by sorting resulted and expected response body arrays before ^^ (some others remarks too ;P)

The test cases have been updated to use chai instead of the old test framework.