Re: A community for REST Content Type development, Was: [rest-discuss] Seeking feedback on the Blinksale API
- Benjamin Carlyle <benjamincarlyle@...> writes:
> Microformats also have an edge over "straight" RESTafarianism. They haveI think you're mistakenly overstating the importance of the data
> a lot of source information to work from when devloping a standard. They
> will only standardise encoding for information already widely published
> on the web, and only when several attempts have already been made to
> define content types for the information. Their process is then to
> cherry-pick the best fits to examples in the wild.
> A similar approach may be able to be taken by RESTafarians defining new
> content types. Using information available on the web may still be a
> viable way to collect samples. As to how these would fit with
> applications that need to use the type, well that would still be
> something of an unknown.
format in a RESTfull system.
It is important that the data format be self-describing in as much as
you need to be able to find out, from an entity you have recieved,
what further entities you can get to and how. But no more than
that. REST is not for defining what an application does with data
outside of interactions.
A list of invoices might be represented in ATOM. But a list of
transactions might also be an ATOM list because ATOM can include
complex data in the content element.
It's not a standard to represent invoices or transactions in this
way. But it would work right? And there is no standard for lists of
invoices as far as I'm aware (there probably is one for transactions).
Another advantage of REST (which Roy was drawing out) is that we don't
always need to rely on heavily standardized data formats. Often such
formats are invented for particular operations (say B2B conversations)
and are ill suited to the sort of light operations that many REST
http://www.tapsellferrier.co.uk for all your tapsell ferrier needs
>>>>> "Scott" == Scott Chapman <scott_list@...> writes:Scott> I've heard that you can't "log out" of a HTTP auth session,