On the last example, I believe a PUT call should respond with an error status for missing fields, and for partial changes we should use PATCH instead. But considering your point to be intuitive, I would say we should send an optional suggestion field in the PUT case but still cause it to error out. e.g.:
{
// Some internal error code for tracking
"code": "MISSING_REQUIRED_FIELDS", // or: -1
// can be used for showing error message in UI.
"message": "Required fields: 'name', 'email'.",
// can be hidden from UI but REST API users can see the help text.
"suggestion": "Use PATCH for partial updates."
}
Awesome share! Completely agree with the human-centric approach. As engineers I think we too often fall in the trap of developing "perfect" solutions in our heads and forget to include the target audience in those discussions.
In a way, I see API design similar to developing a new product: lean principles can help build the most useful thing. This book also highlights how important that is (not affiliated or sponsored, just a fan 😛) manning.com/books/the-design-of-we...
It seems to me they're almost the same thing, except business requirements is more broadly scoped to also consider the need of the business context. I think this is maybe where I'm possibly getting confused and we're mixing definitions.
I'm a developer particularly focussed on accessibility and frontend web performance. Outside of work I'm interested in science, the environment, bouldering, and bikes.
Location
Manchester, United Kingdom
Work
Lead frontend engineer at Co-op in the United Kingdom
I am a Full Stack Developer with 8+ years of professional front-end & back-end development experience using React and Node.js
Recently, I took part in the development of LMS(Learning Management System
I'm Hide. I'm passionate about profitable internet businesses. Currently – consultant and creator. My life's work is toexponentially increase the TGMV (total gross merchandise value) of online busines
Is it a design pattern if you're considering subjective data like human need? That implies that the design pattern is open to interpretation, which is an anti-pattern in engineering
Top comments (10)
On the last example, I believe a PUT call should respond with an error status for missing fields, and for partial changes we should use PATCH instead. But considering your point to be intuitive, I would say we should send an optional suggestion field in the PUT case but still cause it to error out. e.g.:
Intuition should not break conventions.
Awesome share! Completely agree with the human-centric approach. As engineers I think we too often fall in the trap of developing "perfect" solutions in our heads and forget to include the target audience in those discussions.
In a way, I see API design similar to developing a new product: lean principles can help build the most useful thing. This book also highlights how important that is (not affiliated or sponsored, just a fan 😛) manning.com/books/the-design-of-we...
Here’s a guy who knows what’s up. This is a great one, Paul!
It seems what you call human centric is following business requirements in the end.
Can't those two have the same goals?
It seems to me they're almost the same thing, except business requirements is more broadly scoped to also consider the need of the business context. I think this is maybe where I'm possibly getting confused and we're mixing definitions.
@paulasjes I think something might have happened to the content of this article too?
I think this is very useful for dev. Perfect!!! 🙂
Is it a design pattern if you're considering subjective data like human need? That implies that the design pattern is open to interpretation, which is an anti-pattern in engineering
Great