Reputation: 1380
I'm creating an API for submitting incoming email messages for internal processing. The mail server script will submit them in a simple format like, pretty much exactly as received:
POST /api/messages/
{
"sender": "sender@...",
"recipient": "recipient@...",
"email_message": "headers\nbody"
}
However upon submission the email_message
is parsed, some fields are extracted, message body is parsed, etc, and what we actually store as the entity is this:
GET /api/messages/1/
{
"sender": "sender@...",
"recipient": "{our internal recipient ID}"
"subject": "Subject from email",
"date": "Date from email",
"parsed_body": "Output of some magic performed on the Email body",
... etc ...
}
As you can see this is quite different from what was submitted via POST in the first place.
Is this transformation permitted under the REST rules or should the entity be stored (and retrieved) as originally POSTed? And if it should be stored as is then what kind of API endpoint should I provide for submitting the unparsed messages?
Upvotes: 0
Views: 17
Reputation: 57239
Is this transformation permitted under the REST rules or should the entity be stored (and retrieved) as originally POSTed?
For POST, it's fine to store whatever makes sense. Think about how it works on the web; we fill out a form, which submits as a bunch of key value pairs, but the server makes no promise that it is going to store key value pairs.
PUT semantics are different; the client expects the new representation to overwrite the existing representation (if any), whatever that means. So you need to be more aware of the implications of those semantics, especially in regards to what assumptions the client is allowed to make as a consequence of various responses.
POST semantics are much more forgiving (and consequently, the client has less information available about what's going on; that's part of the tradeoff).
Upvotes: 1