Project Concerns

[JakeGinnivan]

First things first. What do we want the scope of this project to cover?

• Core Hypermedia concerns
• Producing HAL
• Consuming HAL
• Producing Collection+Json
• Consuming Collection+Json

If the goal is allowing multiple formatters, we should started supporting both so our design supports both? But with more scope it will obviously slow us down.

@DotNetHypermedia/owners @glennblock

[wis3guy]

I'd say we come up with a simple framework/strategy in a core library first, which would dictate an architecture for format specific implementations. We subsequently use that to implement the HAL format (we have experience with). This way we dog-food our own architecture and flush out initial problems with it.

Then we give collection+json a go, hopefully involving @glennblock or other people working on libraries for that format. In this stage we deal with cross-format inconsistencies and tweak the core.

Perhaps, later on, we might even give UBER a go (https://rawgit.com/mamund/media-types/master/uber-hypermedia.html). I'm quite sure there's more hypermedia driven formats out there I/we do not know about right now and thus cannot architect for.

[wis3guy]

By the way, i also created this little thing in the past : https://github.com/wis3guy/HalClient.Net We might look into that for inspiration or burn it down entirely. ;-)

[wis3guy]

As a starting point for the discussion, this is a diagram i found in my working directory. Again, this is part of the abandoned attempt to use an intermediate object in the serialiser. Perhaps it is still a viable route, given we can solve the client-side i fought with.

[danbarua]

I'm up for giving http://jsonapi.org/ a go when hal and collection+json are done. In terms of architecture, I prefer the approach of intercepting a POCO model and replacing it with a populated Resource Representation over requiring the user to inherit from a base class or implement an interface.

[glennblock]

I am not a fan of the POCO model intercept, though it is a valid approach. I prefer keeping the logic close to the developer / having a model which carries links and hypermedia and a transformation from a domain model to that model through a service. My reasoning for this is Hypermedia is not a cross-cutting concern, it is very real business logic of the system. On Thu, Nov 20, 2014 at 8:34 AM Dan Barua notifications@github.com wrote:

I'm up for giving http://jsonapi.org/ http://JsonApi a go when hal and collection+json are done. In terms of architecture, I prefer the approach of intercepting a POCO model and replacing it with a populated Resource Representation over requiring the user to inherit from a base class or implement an interface.

— Reply to this email directly or view it on GitHub https://github.com/DotNetHypermedia/DotNetHypermedia/issues/1#issuecomment-63836704 .

[glennblock]

I think both approaches should be supported as clearly some prefer to address links in a cross-cutting fashion. On Thu, Nov 20, 2014 at 9:13 AM Glenn Block glenn.block@gmail.com wrote:

I am not a fan of the POCO model intercept, though it is a valid approach. I prefer keeping the logic close to the developer / having a model which carries links and hypermedia and a transformation from a domain model to that model through a service. My reasoning for this is Hypermedia is not a cross-cutting concern, it is very real business logic of the system. On Thu, Nov 20, 2014 at 8:34 AM Dan Barua notifications@github.com wrote:

I'm up for giving http://jsonapi.org/ http://JsonApi a go when hal and collection+json are done. In terms of architecture, I prefer the approach of intercepting a POCO model and replacing it with a populated Resource Representation over requiring the user to inherit from a base class or implement an interface.

— Reply to this email directly or view it on GitHub https://github.com/DotNetHypermedia/DotNetHypermedia/issues/1#issuecomment-63836704 .

[wis3guy]

well, i agree in that it is not cross-cutting, that is why i wanted (but failed) to pass context from the Action to the Service to base decision on. :)

[glennblock]

Dan adding support for JSON API sounds good. I can also add UBER support. Other interesting ones Siren and JSON-LD On Thu, Nov 20, 2014 at 9:21 AM Geoffrey Braaf notifications@github.com wrote:

well, i agree in that it is not cross-cutting, that is why i wanted (but failed) to pass context from the Action to the Service to base decision on. :)

— Reply to this email directly or view it on GitHub https://github.com/DotNetHypermedia/DotNetHypermedia/issues/1#issuecomment-63844794 .