Writeable hypermedia links

[Marten Lienen]

Hi,

are hypermedia links in roar writeable? I went through parts of the source and just tried passing some of the options to `link`, but that did not work.

I our API clients send JSON diffs to update resources and links should also be updatable. So I would like to parse links and create model instances from it to update references etc.

If this is not possible at the moment, how far do you think, I would have to dive in to add that functionality? And can you give me any pointers, where to start?

Thanks,

Marten

[Nick Sutterer]

Hey Marten,

currently, when consuming a document, links are parsed and assigned with `#links=`. We don't know how to "write" them, as links are created dynamically. So, all you have to do is override `#links=` and do whatever you fancy.

Please note that this is Roar from master, I'll release 1.0 today.

Let me know if I can help! Also, can you give some more information what exactly you're doing? It sounds interesting!!

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

[Marten Lienen]

I hoped, that you could pass setter, getter, reader and writer options to #link like you can to #property. But I will try my luck with #links= first.

Which aspect of our API are you interested in? We are building a HAL-API, so all resources are sent to and from clients as specified in the HAL proposal. The tricky part is doing partial updates. The idea is, that our client requests the a resource, manipulates it and then generates a JSON patch with https://github.com/CQQL/rfc6902-json-diff-js. This is then sent back with a PATCH request. On the server side we build the same HAL resource, that you would get with a GET request. Then we apply the patch to it and parse the thing back in with roar/representable and save it.

And when I am saying HAL, I actually mean HAL-JSON, but you could probably guess that from the JSON diff :)

Up until this point everything is quite straightforward. The hard part of the tricky part is updating collections and transitive updates to items in collections. There will be different cases. In the case of an unordered collection, we can just do some sort of member check to sync the collections. If we have a collection with deterministic order and things are moved around in it, we somehow have to recognize that and update some kind of ordering number. In the end it will probably work similar to the JSON patch generation with levenshtein distance. The hardest part will be updating things transitively in an embedded resource in a collection. So for example let's take a recipe and it's ingredients and both are entities in the Domain Driven Design book sense, so that you cannot just replace the ingredients in the recipe, because ingredients have identity. And ingredients are ordered. So when the user reorders the ingredients and changes the amount and unit of some

--
You received this message because you are subscribed to a topic in the Google Groups "Roar" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/roar-talk/488p93BX_h4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to roar-talk+...@googlegroups.com.

[Marten Lienen]

, we have to make sure, that we apply the right changes to the right ingredient objects. Right now I am uncertain, if this will be easy once we have solved the first problem, or hard/impossible.

I accidentally sent the first email, while deleting a word with CTRL+DEL hitting CTRL+Enter :D

[Nick Sutterer]

Overriding #links= has the same meaning as specifying a :setter (which you could also do!). Now, let me ask you, why would a client change a link and send it in a PATCH request? Can you give me an example for that use case?

The underlying logic for hypermedia is here: https://github.com/apotonick/roar/blob/20cd3f471c8709352c64e9ed22559aa2b72ff5a2/lib/roar/representer/feature/hypermedia.rb I simplified that over the last week. The JSON-HAL implementation works on top of that but shouldn't be necessary to look at, as it simply assigns Hypermedia instances via #links=. I'm here to help if you need me.

Regarding your domain problem:

I had a look at JSON-PATCH and also a chat with Mike Kelly about a new format I came up with called "Object-HAL". This format is based on HAL and adds application semantics, like updating, replacing, adding properties, collections, collection items without the pain that JSON PATCH brings.

With all respect, but this is too low-level. The idea of JSON-PATCH is great as it specifies a generic way, however, our domain is models and objects and not JSON documents, so my idea was to abstract this to a usable level.

{

  songs: [

    {id: 1, title: "Mandarin", _op: "update"}

  ]

}

As you can see, you can specify operations per object. This goes hand in hand with Representable's deserializers which are ready to process documents like that.

If you could name some more use cases for updating/replacing/... nested collections, that could help me defining that Object-HAL semantics.

 

[Marten Lienen]

Can you give me an example, how to work with a setter? `link :something, setter: -> ... { ... } do ... end` did not work.

I have to agree, that JSON patch would be tedious to write by hand, but I don't see a problem there, when it is autogenerated. So nobody will ever have to deal directly with it. You can see in this gist, how I imagine the rough shape of client code: https://gist.github.com/CQQL/0e748e1d634efa150391 .  Of course you could exchange the diff format for some other format. The important thing is, that it can be autogenerated.

I also just wrote a first sketch of the corresponding server code: https://gist.github.com/CQQL/286c433f6d293c6c0ced

I also have an example for updating links: https://gist.github.com/CQQL/f8651cc12ed3ad8330bd .  Someone created a recipe and would like to modify it's ingredients afterwards.