DELETE method passes the point of no return ?!

[i-Ching]

1. Starlite version 1.44.0 does not allow delete method to return any result.
   It is impractical for real-life usage.

#from your minimal example:
@delete(path="/{user_id:uuid}")
 async def delete_user(self, user_id: UUID4) -> None:

2. Starlette and FastApi allows DELETE method to return results:
   https://sqlmodel.tiangolo.com/tutorial/fastapi/delete/

3. Aiohttp, Sanic and Quart allow DELETE method to return results too:
   https://sanic.dev/en/guide/advanced/class-based-views.html#defining-a-view
   https://subscription.packtpub.com/book/web-development/9781801076302/2/ch02lvl1sec11/how-quart-handles-requests

4. Because "results of DELETE return" save our extra codes. It make programs simple and direct to match with SQLAlchemy results:
   Delete support the ability to return the number of rows matched after the statement proceeds
   https://docs.sqlalchemy.org/en/20/tutorial/data_update.html#tutorial-multi-table-deletes

My main point is:
I request DELETE method of Starlite passing the point of some return, as same as other competitors
https://youtu.be/D-TgDvyr3g4?t=132

Past the point of no return
The final threshold
What warm unspoken secrets
Will we learn
Beyond the point of no return?

[Goldziher]

Very poetic.

Its not about delete, delete can return a value. Status code 204 does not support content. You can change the status to 200 or something else and return a value.

Regarding other frameworks - you are welcome to try returning 204 with starlette and content and see what happens. Its simply that starlette and fastAPI default to 200 for delete, which is semantically wrong.

[i-Ching]

It works, your solution saves me day, thank you.

@delete(path="/{user_id:uuid}", status_code=200)
async def delete_user(self, user_id: UUID4) -> int:
  with engine.begin() as conn:
    result = conn.execute(
        delete(user_table)
        .where(user_table.c.name == "Simpsons")
    )
 return result.rowcount

Please add your status_code solution to your documentation.
Just like a car driver, I don't know the detail of an engine.
Don't let the next readers misunderstand Peugeot 204,
Actually the engine is more than Mercedes-Benz CLS 200
Thank again.

[cyeganeh01248]

I was having a similar issue until I realized that it was returning the 204 status code. Is there a reason why 204 is being preferred over 200. I feel like a lot a lot of people (myself included) might be expected that the default be to return some sort of object about what was deleted during the method. Therefore a 200 might be the preferred expected result that users might think to use, with the status_code parameter allowing the 204 no-content body version.

[Goldziher]

204 is a conventional status for DELETE, this is the only reason. You can definitely use 200 as you see fit.

[cyeganeh01248]

Im more asking why the use of 204 INSTEAD of 200 as the default. Most other tools and just my general thought process would assume you would want to return a body and therefore return a 200 as default with the obvious option to change that to a 204 and return nothing. And it seems more of an unconventional default (at least to me) to assume no body and default to 204.

[Goldziher]

Some go one way, others the other. I can give you examples, e.g. Django, nestjs etc. Use 204. With delete returning new value in classic MVC Frameworks. This is the reason. It's a choice.

[cyeganeh01248]

Got it. Havent used many traditional MVC Frameworks in the past. Transitioned from Flask to FastAPI to Starlite. That makes more sense where its coming from then. Thanks for the quick feedback.