Linked Data
No CommentsLinked Data has been defined for almost two years now:
- Use URIs as names for things
- Use HTTP URIs so that people can look up those names.
- When someone looks up a URI, provide useful information.
- Include links to other URIs. so that they can discover more things.
But I think it’s just only now that people are starting to do it… about time.
Posted in REST
No Comments
Use app:accept, screw the Atom Categories
No CommentsIt’s been a while since I’ve revisited the Atom Publishing Protocol, so I just had to review (briefly) the latest APP Draft (17) since it’s probably going to be the one that becomes an RFC standard. I noticed something that I must have overlooked before: the app:accept element. Without even looking through the past drafts, I have a gut feeling that it’s been in the APP for quite some time; and I have the feeling that I had a misguided pursuit of using Atom Categories as service type descriptions.
On the surface, one may think that the app:accept is just for giving the mime-type of whatever resource one wants to create in an APP Collection: jpeg, gif, some xml. Let’s look at the “application/xml” mime-type. It describes many many XML documents that represent many resources. One may be a shopping cart order, or it may represent a classified ad. And this is why I may have overlooked the accept element before: a generic mime-type is generally too broad for describing the semantic meaning of the Resource represented using said mime-type.
But, one can aptly describe the what “Service” a server will provide as a side effect after one POSTs a new Resource to a collection (for creation) by using the Accept Extensions as described in the APP app:accept section– note that app:accept refers to Accept Header section (14.1) in RFC2616. Examples of such side effects are the creation of other Resources in other Collections by the server.
So, in the app:accept example in the new APP Draft (17), it is implicitly suggested to use the “type” extension to describe, semantically, what a Collection will accept and process server side. Example: `application/atom+xml;type=entry` for normal atom entries. In my services now, I can add some extra domain specific restrictions on POSTed Resources with an app:accept like `application/xml;type=”http://example.com/online_orders/flower_basket_order.dtd”`. But don’t use DTDs, it’s just an example. 
Or try `application/xml;type=com.example.some.resource.type`. Note that one has to be careful about quoting (”) values. In the first case, I had the separators (as defined in RFC26162) slash (/) and colon (:) in my URI; where as the second case had no separators. And also note that what one (as a good APP citizen) POSTs Resources, not RPC requests.
So what are Categories good for? I haven’t had much time to reflect on that, so maybe it’s good to use Categories if I had a generic “http://example.com/online_order.dtd” resource type that is used for all types of orders: flower baskets, bicycles, or electronics. Have a Collection for bike orders whose category may be “http://example.com/bikes”, and another for Flowers…
And all this makes sense to me because we want to be Resource Oriented, and mime-types are the preferred route in describing Resources. I say this is good stuff.
Posted in REST, Technology, XML
No Comments
Atom Categories, Its Potential
1 CommentCategories were added to introspection documents in the Atom Publishing Protocol (Draft 10). And I think this is way cool! But wait, the Atom Syntax already has categories, and bloggers already can tag (categorize) their posts with words such as joke or serious. This addition only looks like it’s a way for bloggers to better organize their feeds… so what?
Well, think about problem domains outside of blogging; let me just describe this new addition’s potential with an example.
Let’s say I have an APP service for a genealogical database, called PeopleSeeds. And PeopleSeeds outputs Atom Feeds with machine readable genealogical data in the entries’ atom:content. PeopleSeeds will also accept Atom entries containing the same genealogical markup for new or existing resources (Member URIs). Side note: what PeopleSeeds does afterwards with the data is up to the service– it could do data mining, or related searching in Google for additional information.
But the point is that PeopleSeeds can now advertise itself in introspection documents as a Genealogical Service conforming to XYZ rules; and, now, PeopleSeeds MAY formally reject entries that are not categorized as Genealogical Data– it is implied that certain semantic rules (pieces of XML data in atom:content) are required for entries to be categorized as such. PeopleSeeds wants genealogical data, not a blog entry.
This is a big helping hand for the world of loosely coupled auto discovered services. Various clients can now differentiate between genealogical services and blogs. One benefit could be in rich client GUIs, who can now provide customized experiences for its end users: writing blog entries, or adding ancestor data. Or it can search and use equivalent services as backup providers, or whatever.
All this because end clients can now perform auto discovery in a uniform manner, vs haphazardly inspecting a service’s feed data (or using different service discovery mechanisms) which may not reliably describe a service’s capabilities.
I say, “Wow”.
Now the Atom Publishing Protocol really is the platform for a world of loosely coupled services, not just blogs. Woot.
A New Way to look at Networking
No CommentsVan Jacobson has, in his Google TechTalk, many good quotes… my two favorite:
“Data’s got a name, not a location.” — Van Jacobson
“Data doesn’t live anywhere; where ever it is, it’s great.” — Van Jacobson
Posted in Google, REST, Technology
No Comments
REST Quote of the Day
1 CommentA great quote:
Web services build upon HTTP, but they don’t build upon the Web. The Web uses HTTP as an application contract which enables the loosely coupled exchange of documents between applications, while Web services uses HTTP as a bit pipe - as a transport protocol. –Mark Baker
Facebook Developer API, the suck.
3 CommentsMoe just pointed me to Facebook’s Developer API. Facebook claims that its HTTP based API is RESTful… but the use of XML and HTTP (and avoidance of SOAP) does not make an API RESTful. (I sigh and laugh).
Whatever developer team designed the Facebook Developer REST API needs to go back and reread Roy Fielding’s dissertation and W3C’s WebArch Document; they even should reread the documents they reference in their own FAQ:
What is REST?
REST stands for Representational State Transfer. The Facebook API currently supports a REST based protocol; to learn more refer to Wikipedia’s definition.
My Counter-claim, Facebook created an RPC server instead of a REST API.
Fact: All Facebook requests go to a single URL: http://api.facebook.com/restserver.php (except for login.php).
Comment: REST is about exposing Resources in a uniform syntax, on the web we have URIs. Meaning, we have URIs for each resource (many URIs), and can be seen with the example on the REST Wikipedia entry:
With REST, on the other hand, the emphasis is on the diversity of resources, or nouns; for example, a REST application might define the following resources
http://example.com/users/
http://example.com/users/{user} (one for each user)
http://example.com/findUserForm
http://example.com/locations/
http://example.com/locations/{location} (one for each location)
http://example.com/findLocationForm
Working off a single URI breaks the universal syntax and resource ideas, and Facebook commits this sin.
Fact: All Facebook actions are method based, method names are sent along to the single URI as POST parameters.
Comment: If one implements REST via HTTP/XML, then GET/POST/PUT/DELETE are the verbs one uses on given URI represented Resources. Sending method names in the request body is RPC.
That’s it, that’s all that is needed to critique the unRESTfulness of Facebook’s REST API. Even Wikipedia’s own REST entry, itself, states that Facebook’s REST API is not-REST.
Posted in REST
3 Comments
Atom Publish Protocol and GData
No CommentsThe GData protocol introduced an optimistic locking convention, for resource editing, to the Atom Publish Protocol. The introduced method is quite simple: An Atom Entry’s edit URL is unique by version of the resource. Although the Google team’s method just added a version number to the end of the URL, the URL itself can be random and is opaque of semantic meaning. This versioned URL method allows the server to know if a client is trying to update a resource based on stale information.
After some pause, I had a question: Would it be better to have such versioned URLs or would it be better to add meta information in the Atom entry?
The APP draft spec states:
8.2.1 Editing entries with foreign markup
To avoid unintentional loss of data when editing entry collection
members, Atom Protocol clients SHOULD preserve all metadata,
including unknown foreign markup, that has not been intentionally
modified.
This means that an APP client will send back the version information even if it doesn’t know anything about versioning, which would allow for the server to detect version conflicts.
However, the metadata method’s one weakness is in that it only works with Atom Entries and will not work for other Media. Besides this, I have not found any compelling evidence to support one method or another when ignoring the metadata weakness. And I can’t see either method breaking the REST model, so maybe it’s up to the APP Service API designer.
Then my brain took a tangent:
Doesn’t having version based edit URLs (http://example.com/pic.jpg/1/ and http://example.com/pic.jpg/2/) imply that there are two separate resources as opposed to a single resource? In general, should different versions of a resource be modeled as separated resources? Yet aren’t we talking about editing a resource published at a single URL: http://example.com/pic.jpg ? If we have two separate resources, then shouldn’t the published (linked to in a blog entry) URL be the latest versioned URL (http://example.com/pic.jpg/2/)? Or can we say that http://example.com/pic.jpg represents the lastest version in the ‘trunk’? Or am I splitting hairs since they may just be two sides of the same coin?
Ah that’s it for thinking out loud…
Posted in Google, REST
No Comments
A Stateful Subtlety
No CommentsA post over at the counterpoint blog brings up Stateful Web Services.
After reading it over a few times, I believe the post asserts that:
1. SOA and Web Services lend themselves towards a course-grained API. (Which I think it means WS-*).
2. But user interactions require repetitive low-latency fine-grained interactions.
I believe that the post suggests that the client will interact over the network to a server (Web Service) with a fine-grained API(maybe a proxy that sits in front of a course-grained Web Service).
3. And finally its example of, the “Attaching documents to a webmail requires a temporary creation of a resource on the server.” that can be used to achieve fine-grained access. This is used to claim: “statefulness is a necessary evil, but it is mitigated by the service providing a fool-proof interaction sequence.”
I am not opposed to the creation of temporary resources, nor do I have a position on fine-grained vs course-grained.
But, let me suggest that state isn’t something that needs to be stored and managed by the service. Rather, state is just a snapshot of the resources found on the server. A very subtle distinction. And yes, I am suggesting REST.
Posted in REST, Technology
No Comments