Change response message structure

I’m submitting a

• bug report.
• feature request.

Current Behaviour:

Right now hydrus returns a string as response message which contains the information related to object’s ID. If the client wants to access that, it has to use a regular expression to extract the ID from the message.

Expected Behaviour:

We can return a response in which object ID is separated from the verbal message, so a client can access it directly. Ex.

{
"message": "Object successfully created",
"object_id": "deede-w9d2wo-dkwd-fefrr3rt4"
}

@Guttz anything you want to add?

Steps to reproduce:

Do you want to work on this issue?

YES

[chrizandr]

The spec mentions subclassing the Error and Status classes. It also allows us to add additional identifiers to the messages.

Furthermore, a Status or Error returned by the server can also be given an identifier.

This means we can use the @id field in status and objects to provide URIs. In case of PUT/POST these can represent the URI for the instance. For DELETE, I don’t think we really need an ID in the response since the instance with that ID would have been deleted, just a 200 response would be enough.

[chrizandr]

Does the spec say anything about the format of response messages? We should find that out.

Alternatively, we can return the modified object in case of PUT/POST. For DELETE the status code should be sufficient. The reason being that we would have a more standard response rather than ambiguous messages that we need to parse or custom objects where we define our own fields.

Also since all responses are HTTP responses, they have status codes by default. Unless there is an error we should use code 200 for responses. We already have appropriate status codes based on the error implemented in the exceptions.

EDIT: See #396