Closed bwaterschoot closed 7 years ago
@bwaterschoot Thank you for the contribution!
I understand why you need this but i am not convinced that the library should cater for non-standard link attributes. The HAL spec is explicit about what comprises a Link. Question is: Do we want the library to be strict, or loose?
Allow me to brood on this for a while ...
@wis3guy you could always let the client choose by having a loose and strict HAL parser ?
@bwaterschoot I have given this some more thought and feel that your suggestion would be an improvement for the library. I do have some concerns about how to sensibly implement the option. Logically one would extend the IHalHttpClientFactory
and let the setting trickle down the object graph. Yet, i dislike the idea of a consumer opting for strict parsing whilst still seeing non-populated dictionaries on their links.
In other words, this requires not only an optional enum parameter for the factory methods, but also derived types of f.ex. ILinkObject
.
Any thoughts on that?
We are using a super set of the HAL specification where we have extra attributes on links. For example we want to indicate to the client whether or not a certain link can be bookmarked.
Currently the HalJsonParser throws an exception when it encounters an attribute it doesn't recognize.
Instead of throwing an exception the HalJsonParser could store these custom attributes (e.g. in a dictionary).