Question

So I have the requirement that part of the output models must include UI important information. This information is essentially text translations and suggested formats for dates, prices, lengths.

So an example of an output model could be:

{
  statuses : {
    enumValue1 : "Display This Text",
    enumValue2 : "Display This Text2",
  },
  thePrice : {
    value : 3.50,
    formattedValue : "$3.50"
  },
  length : {
    meters 3,
    formattedValue : "3 ft."
  },
  iAmAPropertyOnlyInGet : 42
}

Now if I have this as my output model, is it “ok” to have a completely different input model?

{
  status : {
    enumValue1,
    enumValue2,
  },
  thePrice : 3.50,
  lengthInMeters : 3  
}

Answer 1

Representations you send to the origin server can be completely different than the representations you receive. Consider the way web browsers work. You GET text/html and you POST application/x-www-urlencoded-form.

When using the PUT method it is normal for what you PUT and what GET to be similar if not identical.

The REST architectural style puts no constraints on the shape of the HTTP payloads, other than the fact that the semantics must be explicitly specified in the message.

So, in fact, sharing a model type between a client and server without explicitly identifying that type in the message is a violation of the self-descriptive REST sub-constraint.