Action item from IIW: Handle-free queries
Sunir Shah
Regarding section 4.1 of the spec, we discussed at IIW whether or not
to require xml:ids on <link/s> and use them as keys to retrieve,
modify, and delete <link/>s in the XRD and drop the tuple-query method
of identifying links.
We discussed whether or not the registrant or the registry should
generate the IDs, and I believe the consensus was that the registry
generates IDs in order to avoid collisions, though I may be mistaken.
Personally, with regard to ID collisions which is the third concern I
was going to raise, I believe only the registry server should generate
IDs, not the registrant. I don't feel the need to explore that point
further.
I'd like to defend the tuple-query method.
I understand the general pattern for creating records on a foreign
service and joining them to the local database is to use an generated,
unique ID as the joining foreign key. However, the cases I see involve
companies with millions of customers. They will need to massively
update endpoint URIs for their customers, and so they presumably want
a way to rediscover the registered links that they own (see previous
email about the owner attribute).
I don't believe registrants would store the IDs generated by the
service. That would require them creating a whole database table for
this purpose. I believe they already need to store the OAuth access
and refresh tokens for the directory service, and presumably the OAuth
endpoint. Since many registrants will likely register several <link/s>
for each of the protocols they support (e.g. we'd register the
FreshBooks API itself, plus time tracking, expense tracking,
invoicing, contacts, and payments endpoints), they'd need a second
table to store the 1:many directory->ID mapping.
It'd be easier to just GET the XRD again, scrape the IDs out of the
XRD, and then call the PUT and DELETE methods accordingly.
That's an extra GET for not a lot of value. Imagine that happening 2
million times because PayPal changed its service endpoint. It would be
easier for PayPal to just tuple-query & update by the owner, rel, and
type attribute and providing a new HREF as is described currently in
the spec.
Further, if a customer decided to cancel their FreshBooks account,
we'd like to remove ALL FreshBooks endpoints at once. We'd just want
to make one DELETE with a looser tuple-query of owner="freshbooks" and
be done with it.
Cheers,
Sunir Shah, Chief Handshaker, FreshBooks
(416) 481-6946 x224
http://www.freshbooks.com/team/sunir
http://twitter.com/sunir
Dobes
efficient to have a POST/PUT operation that replaces all prior
registrations for that owner for that user, this would allow a single
operation to just bulk update all the links. I would propose changing
the POST/PUT operation so that it accepts an <XRD> root tag which
contains the links within it as an alternate format to a single Link
tag. For POST all links would be added (if not already present) and
for PUT links are replaced. This is in line with the XRD spec where
the root tag can be either XRD or XRDS.
Also, DELETE could be changed so that any missing parameters are
considered a wildcard; DELETE with no parameters deletes everything
registered by the authorized owner while putting a type, rel, and/or
href would delete all links registered by the owner that match the
parameters provided.
Given that registering or updating several links at once is likely to
be a common use case, I think these may be worthwhile additions to the
protocol.
It may also be useful to have a DELETE operation that spans all users
in the registry, basically allowing a registrant to wipe itself from
the system, or an admin to wipe a registrant from the system, or
similar "cleanup" operations, such as removing viruses/trojans or
whatever you'd call it in this environment.