Client support

[wis3guy]

As we aim to provide a client-side experience as well as a server-side one, i wonder wether it is safe to assume that the consumer of the API has uses the exact same DTO classes as are used on the server.

I can think of scenario's where:

• you would want to return an actual EF entity, but only serialise some of it's properties based on configuration for example.
• you do not know who/what your clients are going to be (my current scenario), so you cannot provide them with a dedicated client, as platforms differ (Java, Node.js, Python, etc).

If we decouple the thought of the .net client experience from the server side experience, we might also conclude that a client should receive a generic ResourceObject rather than the originally serialised object. This is actually the approach i took with my own HalClient.Net project.

From a RAD perspective, this is not ideal, as the client will have to write his own mapping code to turn the ResourceObject back into a typed object, but it does open doors to features on the server end ...

[glennblock]

+1 on having support for clients. But I am thinking about this from a diff angle. I want to use RestSharp as my client over .NET HttpClient. Can this project help me?

As to the specifics, I would say without delving too deep into a framework, it would be nice to have client side abstractions that can be used for consuming hypermedia on the client. This potentially goes much further than just deserializing data and links, to work flows and state on the client. See @darrelmiller's Evolve talk for some good ideas.

[wis3guy]

Yes, i can see why one would want to use a different http client, but hat is just a matter of abstracting things a bit more.

What i struggle with is, what would you need to consume an API successfully. Is it possible to make such a thing generic, or should we just supply scaffolding and expect the developer to tailer it to specific api's.

On HATEOAS in general: My naive impression is that a client must know about API specific aspects (like link relations and how to interpret them) in order to benefit from hypermedia. This leads me to conclude that we cannot do more than deserialize a response into a format-specific resource object and enable developers to work with that, through some helpers/extensions (ie. map into typed objects, follow links).

Going to look at the talk. You meant this one, right? https://www.youtube.com/watch?v=LbSM8U21YkM

[wis3guy]

Ok, looked at the show. Kudos to @darrelmiller for that talk! I especially liked the last part, where people asked the questions, as i struggle with the same things. Going to let this sink in, and wrap my head around this before i proceed with any client related work.