Recent searches
Search options
@ardalis@fosstodon.orgGood article on how to structure DTOs for APIs:
https://shermandigital.com/blog/data-transfer-object-apis-versus-restful-apis/
@ardalis It is good advice about designing resources. It would be nice though if folks could stop creating "REST API" strawmen to knock down.
@ardalis I don't feel like it had any tips on how the dtos should be structured - but more a general argument for using dto.
But isn't that kind of thinking old news? (I'm not talking about the article date.
I haven't worked a place where new projects didn't naturally utilise dtos, without anyone having to make an argument for it.
@mortentoudahl the argument or trade off is between custom dto per endpoint or per client need vs REST resource representations, IME. Article makes a good case for framing that trade off.
@ardalis oh yes, It was a good article. :-)
@ardalis I had never heard of a dto API (although I use the term dto regularly). I can't tell if what I'm writing would be termed DTO or REST by the author on first read.
@ardalis let me state that as a question. Can. REST API return a DTO? What makes it not REST if I return a DTO?
@TimPurdum Yes anything being passed around over http is a DTO. I think the distinction being made is whether the DTO represents the current state of a resource or not. REST would suggest it should, but sometimes some ad hoc data from one or more resources is needed by a client, and it can be efficient and effective to expose less “RESTful” endpoints that return the non-resource DTOs.