Re: Link Relations

<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.
>
>
>
>
> 
>