REST itself is separate from the HTTP protocol.
A Rest based response should represent the current state of the conversation, or at least the delta of change in the state. This would generally be a description of anything new, and information about things they can now do. Exactly like a web page, which describes information (the content) and has links/forms representing actions the user can take.
The fact that HTTP also suggests that you return the new resource location in a header field
location is simply a standardisation, in this case to direct the browser to that content as an automated redirect. So pick the resource that feels best to place here.
HTTP also has a
Content-Location which is meant to hold the location of a returned resource.
Putting these two together the software can return
location with a url that would naturally redirect to, say the newly created domain. Which works for dumb browsers/agents they will now go to the domain. Smarter agents though can take advantage of the fact that the body contains a resource (the
order) and the
Content-Location of that order.
However this is missing the point. This is a Representational State Transfer, so nail down the representation. What are you being given and, how are you responding?
Sounds like the user is giving you the domain name. Presumably success means that this is now a thing. It is indeed a resource, but do you need to repeat to the user what they just said?
Sure it is legitimate, but what is being achieved here?
What else is happening? The server is making an
Order resource. Does the user know about this? Probably not, or at least they don't know where it is.
And the order doubtlessly also includes a link to the domain, should they have forgotten what they were requesting.