Please make a video about a more domain-centric API design, maybe with CQ(R)S. In my experience, level 2 "REST" APIs are oftentimes just "database CRUD over HTTP", leading to leakage of implementation details into the public API of the service, which results between high coupling between a client and the server implementation, which is a malpractice in my opinion. Despite that you loose semantic information about the actions performed in your system early on, as you push the usecases of the domain upwards, basically to the clients. For example, what does a "PATCH /api/todo-items/3" mean? Has the TODOs title been changed? Has it been ticked of? Marked as irrelevant? Has someone been assigned to the task? A combination of these actions? Compare this with a more domain-centric command based API design, e.g. "POST /api/commands/tick-todo-item { id: 3 }". I personally think the latter one is far more descriptive and does not loose the domain semantics early on. Don't get me wrong here. I think a more resource based approach can be useful, e.g. for more "backing services", but the more an API is designed for a specific domain problem, that being "closer to the end users", the less REST is helpful in my opinion.
big word there . why limit rest or url ? the old way you dont have think one endpoint is enough . you dont need /api/read / api/update/id. This style of routing much better for web crawling but no point on intranet application.
Please make a video about a more domain-centric API design, maybe with CQ(R)S.
In my experience, level 2 "REST" APIs are oftentimes just "database CRUD over HTTP", leading to leakage of implementation details into the public API of the service, which results between high coupling between a client and the server implementation, which is a malpractice in my opinion.
Despite that you loose semantic information about the actions performed in your system early on, as you push the usecases of the domain upwards, basically to the clients.
For example, what does a "PATCH /api/todo-items/3" mean? Has the TODOs title been changed? Has it been ticked of? Marked as irrelevant? Has someone been assigned to the task? A combination of these actions? Compare this with a more domain-centric command based API design, e.g. "POST /api/commands/tick-todo-item { id: 3 }".
I personally think the latter one is far more descriptive and does not loose the domain semantics early on.
Don't get me wrong here. I think a more resource based approach can be useful, e.g. for more "backing services", but the more an API is designed for a specific domain problem, that being "closer to the end users", the less REST is helpful in my opinion.
big word there . why limit rest or url ? the old way you dont have think one endpoint is enough . you dont need /api/read / api/update/id. This style of routing much better for web crawling but no point on intranet application.
Nerd tv at its best 👌
rest in peace
Umm... Sudden end. Where is the rest part?
Dr Strange? magic
Man what are you coming to say
Good
that screen recording is in 144p
Hi
I think it's not for beginners.
What a long and boring video...