Re: reusing Vocabulary terms in Social API (Hypermedia)

> On 28 Jan 2015, at 07:30, A.Kuckartz@ping.de wrote:
> 
> I spent some time recently to understand what REST and HATEOS really are about and that is the background for the few comments below. 
> Evan Prodromou wrote:
>> I mentioned today that most proprietary APIs don't follow this principle (Facebook might be a notable example). They instead have documented URI patterns that developers can use to query the data they want.
> 
> Yes, but the companies controlling these proprietary APIs generally are interested in lock-in, not in improving the web or in defending openness. That is one reason why we have countless different "Web APIs" and in 2015 still need to waste huge amounts of developer time in writing clients from scratch again and again instead of using machine readable API specifications. 

completely agree. This is the place where we have to move away from proprietary APIs if we 
want to build a Social Web. We also need an API that will work for systems that need to have
opaque URLs for security/privacy reasons

>> They will see that if they want to get to your list of friends, all they
>> have to do is append "/friends" to the URL they used to retrieve your
>> profile data.
> 
> Maybe it makes sense to specify this for the server, maybe not. In any case it would help to provide the client with machine readable information about this. Requirements for clients and servers can be different. 

+1


>> It just doesn't make sense for them to do 2 HTTP requests to the API and parse through the links information when they know very well exactly
>> where your friends stream is going to be.
> 
> A generic JSON-LD client (which does not know anything about the Social domain) will not know that if this information is not made available in a machine readable format. 

If you know someone's profile the chances are that you have already requested the profile information,
and have a link from that to the friends profile. 

>> Imagine retrieving and caching thousands or millions of profile documents just because you don't want to "assume" that the friends document will be exactly where you know it will be.
> 
> Premature optimization. 

Agree. Also it seems a bit weird that someone would want to know someone's friends without 
knowing who they are?

>> Once enough client programmers use the "short cut" of following URI patterns, there will be pressure on other server implementers to
>> implement the same pattern. Especially if there are some platforms that
>> are more popular than others! The less popular platforms will use the
>> same URI patterns as the more popular platforms in order to assure client
>> software compatibility.
>> At this point, we'd have a /de facto/ URI pattern standard, undocumented or poorly documented, that everyone would have to use.

I don't think that such a url standard can be made to fly. It breakes HATEAOS, and
is bad practice. It is also very inlfexible. You'd need to decide a URL pattern
for the huge number of relations that people may have. What if people want to point
to colleagues, to family members, to specific interest groupes, etc...? We would have
to specify URL patterns for each of those. 

Finally this assumes that the default setup is one huge server with millions of
profiles on them, whereas I am imagining a Social Web with millions or billions 
of servers, each with a small amount of profiles on them connected to each other.

> 
> Agreed, that is a dynamic which we should be well aware of. Thanks for stressing this. 
> Please do not let us throw things under busses. Sometimes people are hurt when that happens. 
> Cheers,
> Andreas 
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 28 January 2015 15:00:26 UTC