4 ms·
> I am tempted to merge it with the HTTP model as well, add JSON tags to it. If you add a property which shouldn't be public you have to separate them. For ex
by kenniskrag 5y ago
> I am tempted to merge it with the HTTP model as well, add JSON tags to it.
If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email.
Second argument: I usually create a simple struct for each method. For example I do not want, that they provide the id for post requests. I want to send the id on get requests so that they can send an update request with the id. I prefer only "non-null" arguments and as a bonus you get a clean (auto-generated) api documentation.
- 5e92cb50239222b 5y ago> in the domain model you have a user with email but do not want to expose the email. You can usually configure that out with @JsonIgnore or something like that. Although this works only for this particular (very simple) example and won't help with e.g. flattening multiple nested objects.
- williamdclt 5y agoAt this point you already have 2 "models", in the sense of 2 "concepts" or 2 "types": the one with the field and the one without. The second one is implicitly defined with these annotations, which has a good chance to be annoying sooner or later when you need it to be explicit.
- kgeist 5y ago>If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email. Another possible problem: having to support two versions of the API at the same time.