Looking for feedback: Traverson, a JS hypermedia client library

[Bastian Krol]

Traverson is a small JavaScript library for working with hypermedia APIs. It works in Node.js and in all major browsers. I really would love to get some feedback from the api-craft folks on this!

The core feature of Traverson is to make it very easy to follow a sequence of links to a target resource. That is, you hand it a start URI (the root URI of the API) and some link-rels and Traversons traverses the links for you and returns the target resource to you once it is finished.

It also supports HAL, URI templates, JSONPath and some other stuff.

What do you think? Is this actually useful? What features would you like to see?

Links:

• Slides: https://speakerdeck.com/basti1302/consuming-hypermedia-apis-with-traverson (introduction of Traverson starts at slide #11)
• Blog post: https://blog.codecentric.de/en/2013/11/traverson/
• GitHub: https://github.com/basti1302/traverson/

Kind regards

  Bastian

PS: I also posted to hypermedia web a few weeks ago, but this went unnoticed so I thought I might try here, as this group seems to have more traffic and participants. Sorry for crossposting, though.

[mca]

I did a quick scan of the material and that links. here are my comments:

1) very cool idea of making link-following  a "built-in" feature. I like the handling of URI templates, too.

2) not so happy about the path-following, tho. IOW, looks like the code is bound to a single path of links to get to a result. that means changes in the server paths will break the client. would be nice to be able to do something like provide a starting place and an ending place and allow the client code to figure it's own path based on server responses.

3) cool support for HAL. any plans to support other hypermedia formats (including HTML)?

BTW - sorry you didn't get any ping from me on the hypermedia-web list. this is very interesting stuff.

Cheers.

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

--
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 http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/groups/opt_out.

[Bastian Krol]

Thanks for your input.

2) not so happy about the path-following, tho. IOW, looks like the code is bound to a single path of links to get to a result. that means changes in the server paths will break the client. would be nice to be able to do something like provide a starting place and an ending place and allow the client code to figure it's own path based on server responses.

That's sound very interesting! Could you elaborate on that point? Currently I have no idea how that could be realized. What kind of server responses would enable the client to _dynamically_ find a path to the target resource/ending point, if not by a fixed sequence of link relations that it can follow?
 

3) cool support for HAL. any plans to support other hypermedia formats (including HTML)?

Definitely. Currently I'm thinking about splitting Traverson into a core module and some plug-in mechanism to include different media types as needed, for example one plug-in for HAL, one for cj, one for HTML based messages. Mason also looks very interesting and I would like to support it. However, this is all quite a bit of work and before investing more time and effort, I wanted to check if there is a place for tooling like Traverson in the hypermedia-/API-space.

Kind regards

  Bastian

[Alexander Scherbanov]

Hello.
Is there any client that does figuring out a path as described in point 2)?

[Alexander Scherbanov]

Hello, Bastian. I like your library and I'm trying it right now. Can't give you any meaningful feedback, because I'm not an expert in apis.

Excuse me for (possibly) a silly question.
I've read many discussions of rest and haven't seen anything like point 2) which assumes clients are so smart that they find new paths in state machine's graph when it changes.
Wouldn't this break not-so-smart clients built to be just-restful, not smart-restful?