generic client patten for form handling

[Edgar Sioson]

Hello,

I'm looking for opinions on which of the following generic client pattern is better from a hypermedia developer perspective:

//option A

client.submit(resource, action, inputs, successHandler, errorHandler);

- OR -

//option B

resource[action](inputs, successHandler, errorHandler);  

Option B seems more elegant, but means that the generic client would convert the 'form' link into a function or method. Option A is more verbose but preserves the resource's structure.

Maybe someone prefers another pattern after considering one or both of the above options?

Thanks,

Edgar

[Tom Christie]

Hi Edgar,

  I'm working on a generic client as part of this project.

Initially I started with transitions being represented as methods on the resource itself (because it mirrored a non-networked Object API), but I've since moved to your (a) version, of `client.action(...)`.

Two benefits:

* Keeping the transport information out of the resource itself ended up being a much nicer separation of concerns.

* It allows custom client instances to be used, and persist any information on transports and encodings there, rather than having to keep that information attached to the resource. For instance - you might want to customize the client to include some particular headers, to sign outgoing requests, or to accept some non-default set of encodings. Having all of that information bound to a `client` instance works rather nicely.

I found it an interesting little point in the progression of the design - having started with `resource,action(...)` and since moved to `client.action(resource, ...)    it feels like the later more properly represents a explicit network interaction rather than naively trying to mimic an object interface.

Hope that helps some,

   Tom

[Kevin Swiber]

Hey Edgar,

I've become fond of using reactive programming libraries for hypermedia clients. They have a number of great features like retry methods. Here's an example of doing this with a Siren client in Node.js: https://github.com/kevinswiber/node-siren/blob/master/example.js. And here's a client that works with a Siren API that uses reactive programming for iOS:
https://github.com/zettajs/ZettaKit.

After several iterations writing hypermedia clients, I've found this to be the best approach in terms of power, convenience, and flexibility. It's composable and resilient.

Regards,

Kevin

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[J Fernandes]

Hi Edgar,

I've been developing a kind of case-study around Hypermedia clients and some of the patterns I found most useful in the past few projects I've worked on. (I should be releasing that in the next few days to a repo next to you).

To make a long story short, and relating to your question, I usually look at links/actions as autonomous in the way that they should have everything they need to execute.

That means my applications don't really need to go through the current response looking for actions and setting up fields, etc.

The links/actions execute themselves and bubble up the response through the current response object graph in a way to promote behavioral flexibility at every level (use cases depend on application requirements).

I would be interested in knowing if that makes sense / relates in any way to other people's experience.

Thanks,

Joao Fernandes

[Jørn Wildt]

Tom,

> Keeping the transport information out of the resource itself ended up being a much nicer separation of concerns.

Sorry if I misunderstand you, but it seems to me that the whole point of using hypermedia is that the resource itself should include the transport information? A link includes the URL and assumes GET - and some sort of "forms" control includes both URL as well as HTTP method and more?

/Jørn

[Tom Christie]

> Sorry if I misunderstand you, but it seems to me that the whole point of using hypermedia is that the resource itself should include the transport information? A link includes the URL and assumes GET - and some sort of "forms" control includes both URL as well as HTTP method and more?

hi Jørn,

I'm referring to stuff that's specifically outside of the remit of the hypermedia affordances there. Ie. Not the method and available parameters, but eg what media types do I want my client to support, what User-Agent should it present, are there any credentials or request signing that's outside the bounds of the hypermedia, etc...

Cheers,

  Tom

[Edgar Sioson]

All: Thanks for the input. I've read through the links, lots to think about.

Tom: I see how in some programming languages the form-handling variables/configuration settings becomes properties of the resource/object instance. However, in javascript it's possible to attach stateful functions, each set with its own configuration variables at the time of 'instantiation'. So, in that way the function does not have to have access resource/object properties. At least that's what I was thinking of doing as option B in javacript and PHP, something like >> resource.edit = new Form({ ... config settings ...}).

Kevin: Is subscribe() similar to a promise.done()?

Joao: I'll be interested to see your case-studies.

--

You received this message because you are subscribed to a topic in the Google Groups "API Craft" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/api-craft/5_V2BXDAT5c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to api-craft+...@googlegroups.com.

[Kevin Swiber]

Hey Edgar, subscribe takes three functions: onNext, onError, and onCompleted. Learn more here: http://reactivex.io/intro.html

The reactive mindset forces developers to think in terms of streams instead of arrays. The composability makes it trivial to chain transformations or merge new streams. I use it to compose asynchronous workflows on top of hypermedia APIs.

You received this message because you are subscribed to the Google Groups "API Craft" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.

[Yiak Wang Yi]

I actually recommend you to use the following pattern

resource.action(behavior, args, source, (function(){var o = new generic_handler_object(), return  handler(o, behavior, args, source) } )())

generic_handler_object will be responsible for success or error implementation and reusable. 

generic_handler_object.action include submit, redirect, ... and error prompt

for example:

function handler(o){

 try{

   var args = argument.to_list(): 

   o.submit(o, args);

 }

except(e){

   o.err(args);

 }

}

在 2016年1月17日星期日 UTC+8上午3:15:01，Edgar Sioson写道：

[J Fernandes]

Hi Edgar,

Sorry for the late reply.

You can now find the case study I was mentioning at: https://github.com/JoaoRXFernandes/AnHypermediaEngine

Hope you find something useful in there.

Please don't hesitate with feedback/queries; Always interested in learning more.

Cheers,

Joao

--

You received this message because you are subscribed to the Google Groups "API Craft" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.