Mike Orr wrote: > I googled around to see how other people are combining Atom and HTML. > It looks like Atom is an advantage only if you want to syndicate the > resource. And even with that, if you only want to syndicate it > read-only but require all changes to be done at the original website, > it looks like only the "index" and "show" URLs need to be conformat > (/article/ and /article/1), and the modify URLs can be anything. And > the index URL would have to provide a bona fide XML atom feed, not an > HTML page with hyperlinks.
Remembering atompub again, it's really pretty loose on URLs. There is a service document which is kind of the frontend. That points to a collection, which is what everyone thinks of. The collection and service document point to each other, they don't have to have any particular URL layout. The collection should produce the entries as a feed. That feed can be paged (and probably should be) so while the collection has a head, to get the complete collection there's multiple URLs, and those URLs are again pointers. Each entry has a pointer to its URL, which can again be anywhere. The collection's main URL must accept POST. The entry URLs must accept DELETE and PUT. You can lay out those URLs however you want. It could be: /atom.xml - head /atom-pg2.xml - for paging /entries/2008/01/29/asdlkfjkj.xml - for the entry /entries?id=3493 - another entry option Really atompub doesn't care at all, and though the examples tend to suggest a certain logical structure, it just a very loose suggestion. You can cross domains or use query strings or whatever. Clients can suggest URL slugs, but it's just a suggestion, and there's no indication about where in the URL the slug may appear. > So, I think this means map.resource is good at what it does -- Atom > serialization -- but it's not a complete answer for how to organize a > set of index/show/add/modify/delete operations in a website. I've > thought about keeping map.resource as-is and adding another more > flexible method for HTML resources that want to be standardized and > somewhat REST-like but not necessarily completely REST, and using GET > for forms and POST for execution. I haven't yet gotten into the > design, though one-method "foo/add", "foo/1/edit" and "foo/1/delete" > are a possibility, optionally expandable to the two-method style > (ask_delete, confirm_delete, something like that). Are there any good > standards or precendants to guide this? Note there's a possible namespace collision between /collection/add and /collection/item-id... what if the item-id is "add"? I'd be more inclined to use a query string, like /collection?form=add. Maybe "form" is a better indication than the common "action", as the point is that these forms (in proper REST style) aren't actually doing anything. Ian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
