Error resources

[joepio]

Having machine readable errors is essential for getting a good user experience while dealing with forms. For example, if some username has been taken, we want to show an error in that specific field.

There are basically two ways to deal with this: have an endpoint for checking specific fields (tight coupling) or having machine readable, structured errors that the client can parse (loose coupling). The second approach is far more powerful, but it requires that Errors become semantic.

I think introducing an Error class is a valuable time investment.

But how do we deal with @id? An Error doesn't always have a logical URL / Subject.

Some ideas:

• Don't give an @id. Let the client deal with this issue. In Atomic-Data-Browser, this may be a problem, as the store uses @id as keys. So we can't render Errors as is they were resources - which kind of is the entire point, of course! We can circumvent this by setting the @id in the client when the error comes in, if possible.
• Generate an @id. We can create pretty random URLs that we don't persist. The URLs would not resolve, but the client may be able to use them.
• Error endpoint. Put all the data in the query parameters. This means a bunch of data duplication. But it would resolve!