hAtomPub Re: Interface definition languages and service registries for REST services
Hi Mike,
On Aug 10, 2007, at 8:24 PM, Mike Schinkel wrote:
One thing I dislike about AtomPub, and I know I'm probably in the minority here, is it requires special tools to interact with vs. just having a browser, and it requires web services be created in addition to web pages. I'd really advocate for exposing webservices as a default case via semantic HTML instead of AtomPub though AtomPub could be the default second case in "the world according to Mike."
I would love to see someone define/build a hAtom version of AtomPub, that worked in standard web browsers:
Hi, I'm fairly new to all things REST (and Web Services in general), but I do have some questions for you. Namely: - What do you think of the idea of having an...
... Forms indeed are a key piece that needs to be looked at. I have found it inspiring to think of forms as questions available for the user agent to answer....
Hi Henry, ... Thanks! I've added it to my REST Service Descriptions page: http://microformats.org/wiki/rest/description#Proposals.2FExamples Best, -- Ernie P....
... Now that sound good. It's still an IDL isn't it ? It's just distributed directly by the service provider and is not exportable. But this and WADL are...
... Somewhat. AIUI, WADL is still a development-/compile-time description. Once you've written software to the described API, you're tightly coupled to that ...
... http://bitworking.org/news/193/Do-we-need-WADL ... We have one failed approach (with UDDI) already; not sure why we'd need another one. For enterprisey...
... Well, this makes a case against WADL, based on - experience with WSDL showing that people will want to generate code from it - the fact that current schema...
... Olivier, 1. signature!=interface. The original definition by D.L. Parnas defined interface as signature+semantics. In the absence of a formal language to...
Steve Loughran ... Agreed, as implemented. ... Doesn't that just push the problem elsewhere? Now we have atom being used for lots of different things with the...
... If Atompub is a close enough match to your problem domain, then that part of the confusion gets resolved; the *rest* is pushed up the stack, but it’s a...
... Oh, I concur that AtomPub is useful in many contexts but, as you imply, not all. Advocating it to be only solution needed is shortsighted, IMO. Don't you...
... With a caveat; namely that I think Atompub is applicable to many more contexts than people might realise. So I think it worthwhile to tell them to try it...
... And in the case where it is a good fit, there is then a need to again define the interacts for each use-case (beyond the nomimal case of "publish.") One...
... Sure, but they’ll have to define those anyway. Atompub just takes care of predefining the lower-level machinery so it doesn’t have to be reinvented...
... Of course, but there are still many things in the use-case domain AtomPub doesn't address so we end up having to deal with those. Hence back to the same...
... No, not the *same* problem – just the *application-specific* part of the problem. The common parts of the problem are factored out to Atompub. But...
... Sigh. I agree with your points here, but I can't seem to get you to understand mine. Maybe I'm just too tired and we'll just have to leave my points for...
Hi Mike, ... I would love to see someone define/build a hAtom version of AtomPub, that worked in standard web browsers: http://microformats.org/wiki/hatom Any...
... I'm wondering if hAtom would be the simplest thing that could possibly work. Do we really need to burden the client with the ceremonial stuffing of the...
Hi Olivier, ... I think there is a conflation of ideas here. My most widely cited weblog entry (that started life as a post on this list) goes into this: ...