Re: Link Relations

> LOL! are you just making sh*t up to see what we come up with?

Yes and no. There are so many *bad* examples, it's hard to find good ones
from which to learn. I do need syncing/ingestion for what I'm doing. My
questions are really about the right way to expose this functionality via
hypermedia controls, what to use for rel values, and so on. Right now,
leaning towards this:

{ "collection" :
  "version : "1.0",
  "href" : "https://friender.com/api/friends".
    .
    .
    .
  "links" : [
    { "href" : "https://friender.com/api/sync/friends", "rel" : "sync" }
  ]
    .
    .
    .
}


On Sun, Nov 10, 2013 at 11:17 AM, mike amundsen <[email protected]> wrote:

> <snip>
> But there is an edge case... Last week, there was a Category 5 hurricane
> that went right through data center, and while your site was down, your
> users went to plain-old Twitter and added some friends.
>
> Now your dashboard and twitter are out of sync. We need to be able to add
> "friends" without creating them on Twitter.
>
> I'm wondering how you all would approach.
> </snip>
>
> LOL! are you just making sh*t up to see what we come up with?
>
> if you what you need to do is offer a sync service, then create a resource
> that exposes the required state and allow clients to manipulate that state
> via representations using a hypermedia control that describes the
> representation transfer.
>
> Here's a possible solution to manipulating state between two storage
> locations that the server already associates w/ your login-context (e.g. no
> need for the client to tell the server what locations to sync up).
>
> <sync href="..." rel="http://example.com/rels/friends" />
> HTTP.GET to return the status of your sync state (e.g. are you in-sync or
> not?)
> HTTP.POST to initiate the sync process
> and so forth.
>
> Of course, if you want to create a more complicated state management case;
> one where the client is allowed to select one or both of the storage
> locations for syncing, then you need a hypermedia control that allows
> clients to include this additional state information:
>
> // Just how the client would *know* these values is another matter but you
> can work that out as needed.
> <sync href="..." rel="http://example.com/rels/friends">
>   <data name="source" value="" />
>   <data name="target" value="" />
> </sync>
> HTTP.POST to initiate the sync process
> and so forth.
>
> In this case, the POST action might return a 201 w/ Location showing a
> resource that representations the state of the sync progress. There are
> other possibilities, too.
>
> Keep in mind you are not managing *objects* (e.g. friends) here, you
> are manipulating state by exchanging representations (hence the name
> REpresentational State Transfer).
>
> Cheers.
>
>
>
>
>
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://www.linkedin.com/in/mamund
>
>
> On Sun, Nov 10, 2013 at 1:10 PM, Charles Reese <[email protected]>wrote:
>
>>
>>
>> Jan, Mike, dret:
>>
>> I guess publishing is a bad example. As dret writes, I can use a status
>> field and watch when it changes.
>>
>> So... a better one.
>>
>> Suppose you want to create a dashboard for Twitter to manage all your
>> friends. You can start by creating a resource with a link relation called
>> "https:/friender.com/rels/friends" along with the usual methods:
>>
>> POST: to follow
>> DELETE: to stop following
>> GET: returns a list of all your friends .
>>
>> But there is an edge case... Last week, there was a Category 5 hurricane
>> that went right through data center, and while your site was down, your
>> users went to plain-old Twitter and added some friends.
>>
>> Now your dashboard and twitter are out of sync. We need to be able to add
>> "friends" without creating them on Twitter.
>>
>> I'm wondering how you all would approach.
>>
>> Cheers,
>> Charles
>>
>>
>> On Sun, Nov 10, 2013 at 8:42 AM, Erik Wilde <[email protected]> wrote:
>>
>> hey jan.
>>>
>>> > On Nov 10, 2013, at 2:23, Jan Algermissen <[email protected]>
>>> wrote:
>>> > Make the state a resource and modify that:
>>> >
>>> > PUT /playlist/77626/state
>>> > Content-Type: application/vnd.foo.state
>>> >
>>> > <state>live</state>
>>> >
>>> > Personally, I aim for avoiding the need to introduce a media type for
>>> this ...
>>>
>>> why create a separate media type? you're designing the playlist media
>>> type anyway, including a fragment that's embedded in the playlist
>>> representation to indicate the playlist status. simply allow PUT on a
>>> linked sub-resource with the exact same syntax. all you have to do is
>>> create a new document/message type in your media type: problem solved.
>>>
>>> cheers,
>>>
>>> dret.
>>
>>
>>
>>
>> On Sun, Nov 10, 2013 at 8:42 AM, Erik Wilde <[email protected]> wrote:
>>
>>> hey jan.
>>>
>>> > On Nov 10, 2013, at 2:23, Jan Algermissen <[email protected]>
>>> wrote:
>>> > Make the state a resource and modify that:
>>> >
>>> > PUT /playlist/77626/state
>>> > Content-Type: application/vnd.foo.state
>>> >
>>> > <state>live</state>
>>> >
>>> > Personally, I aim for avoiding the need to introduce a media type for
>>> this ...
>>>
>>> why create a separate media type? you're designing the playlist media
>>> type anyway, including a fragment that's embedded in the playlist
>>> representation to indicate the playlist status. simply allow PUT on a
>>> linked sub-resource with the exact same syntax. all you have to do is
>>> create a new document/message type in your media type: problem solved.
>>>
>>> cheers,
>>>
>>> dret.
>>
>>
>>
>>
>> 
>>
>
>