How To - Discover Registered Services

From The Socknet

Services and friends can interact with a user's services if they can discover what services that user uses.

The services function facilitates this. It accepts an object which specifies a protocol. All services that the user uses which support that protocol will be returned (at the user's discretion [as always]).

Specification by Example

http://photoprint.com wants to find out what services user1 has that use the http://photostandards.com/photoxchange protocol. http://photoprint.com might register with the user first, because it may get more results that way.

POST services
{ from: { serviceid: "http://photoprint.com/agents" },
  protocol: "http://photostandards.com/photoxchange",
  return: "http://photoprint.com/thing-i-am-doing"
}

->
{ services: [ { serviceid: "http://big-photos.com/agents",
                protocols: { "http://photostandards.com/photoxchange": 
                             { public_data: ... anything at all ...
                             }
                           }
              }
            ]
}

There may be more filtering variables available in the future.

photoprint.com will then check the public_data field in each service to see if the service really lives up to what photoprint.com needs or expects. That is protocol-specific information.

The response may instead be a redirect.

->
{ redirect: "http://provider.com/user1/verification/28582"
}

If so, the user should be sent to verify that he wants to share his list of services with the given service. When the user returns, the service may make the request again and receive a real response (but perhaps an empty one).

The response may include a protocols field at the top-level. This is used for non-service-related protocols, such as RSS2.

There is no mechanism in this specification for adding a protocol without adding a service. IE, non-service-related protocols are setup by the Socknet provider, often through direct interaction with the user.

Considerations

Some services will use full-fledged third-party protocols to communicate. In those cases, the public_data will contain connection information.

Other services will find that all the information they need can be passed in the public_data field. They may never need to communicate directly.

public_data is named that because in future versions of the protocol, a querier may identify itself, and, if a friend, friend_data will be returned and if a registered service, service_data will be returned.