I would be interested in having a feedback on the API Design for the cases resources cross reference ( GET /carts/123/items/321) and add item to cart (POST /carts/123/items:add) .
What is your opinion on having a flat API instead of the nested one you propose?
* Create one item POST/items
* List cart items GET /items/&cart=123
* Retrieve item X GET /items/321
In past I tried nesting resources but it gets quick;y messy and leads to code with higher coupling.
I wonder how it would work in case if the cart id already contained a colon, i.e. consider the following URL: /types/my:type, it already contains colon in type name, thus using ":add" verb might create some ambiguity
Thanks super work as usual!
I would be interested in having a feedback on the API Design for the cases resources cross reference ( GET /carts/123/items/321) and add item to cart (POST /carts/123/items:add) .
What is your opinion on having a flat API instead of the nested one you propose?
* Create one item POST/items
* List cart items GET /items/&cart=123
* Retrieve item X GET /items/321
In past I tried nesting resources but it gets quick;y messy and leads to code with higher coupling.
I wonder how it would work in case if the cart id already contained a colon, i.e. consider the following URL: /types/my:type, it already contains colon in type name, thus using ":add" verb might create some ambiguity
Thank you Alex!
Thanks, Alex!
I've never saw a pattern like `POST /carts/123/item:add`. Why not `POST /carts/123/items`?
Great read with insightful information that enlightens the mind. Recently I tried my hand at some tech writing, AI is coming and I thought I’d put together a rounded article—would love your eyes and insights 😊 https://tumbleweedwords.substack.com/p/ai-enters-our-everyday-reflections