[Zope3-dev] Final(?) "Safe" Character List
Craeg K Strong
cstrong@arielpartners.com
Fri, 07 Jun 2002 20:44:07 -0400
Hello:
Being involved in a Zope-2-based development project with a vicious deadline
(read "deathmarch") I apologize I have not been able to keep up with the
discussions on Zope-3 as much as I would have liked.
I believe I understand the need for the naming conventions for the
various views and things, but I wanted to ask a question:
Have any of you-all been following the traffic on REST-discuss or the REST
wiki? (REpresentational State Transfer)
http://internet.conveyor.com/RESTwiki/moin.cgi/
Unfortunately, the content is a bit all over the map right now as the community
is very new, but I believe their main point is to try to design URL space as
carefully as you might, for example, a relational database schema -- in the
case where both are being used as "flattened" views of an object-oriented model.
They contrast URLs like this: http://acme.com/aladdin/asset/CommandLine
to this: http://acme.com/aladdin/control.jsp
If I am manipulating an "Asset" called "CommandLine", the former
is (obviously) preferred. You then have many potential benefits such as
- not exposing implementation technology in the URL
- more "long-lived" URL
- compatibility with other important standards (RDF, etc.)
The main problem we (at Ariel) have had with the REST people is that they
oversimplify: they believe that you can take any arbitrarily complex
OO model and fully represent it in URL-space by reifying relationships
(they call it "noun-izing") and restricting yourself to just four methods:
namely the ones HTTP gives you: GET, POST, PUT, and DELETE
However, if this results in a design where (in the example of web services)
you have to process potentially highly complex XML streams coming at
you over "POST", you are merely pushing the complexity down a level,
not avoiding it. By contrast, having a set of conventions for "extended
URLs" such as what you are suggesting could be a big help.
I am wondering if the REST community and the Zope-3 community don't have
something potentially valuable to offer each other? Already, Zope-2 may
be the most REST-ful system out there: object to URL mapping is intrinsic
to Zope-- you basically get it for free.
Zope-3 real-world development experience could help out the REST folks
to discover that in fact there are many different possible views for a
given object (aka "Resource" in REST parlance) based on context, where
context is the union of user/role/action/locale/ etc. HTTP's four
methods are way-insufficient to cover them all in a single URL, but
Jim, Guido, et al are proposing a set of "extended URL" conventions
that the REST community might agree with and be willing to promulgate.
REST discussions could help the Zope-3 community to think about how
to ensure Zope-3's friendliness to REST-styled web services, and perhaps
to take more advantage of what is already available via HTTP
(one example: doing an HTTP "PUT" to represent creating an object instead
of a "POST" is an interesting idea-- if every publically exposed object
is uniquely represented by a URL, it sounds like a reasonable fit)
Thanks for reading.. I am sure we are all on tight schedules :-)
but cross-fertilization can be a GoodThing...
Regards,
--Craeg Strong
Jim Fulton wrote:
> A bunch of us here in Fredericksburg discussed this at our
> weekly "Jam" session and came up with some interesting ideas.
>
> First, I'll suggest that while there are a lot of namespaces
> that could show up in URLs, a small number will be common in "outside"
> URLs, as opposed to URLs used by site managers and component developers.
> Currently, these are the view namespace and the create namespace. For these,
> the following hieroglyphics are kinda nice:
>
> @@ for views:
>
> http://foo.com/folder1/folder2/@@/ManageRolesAndPermissions.html
>
> or:
>
> http://foo.com/folder1/folder2/@@ManageRolesAndPermissions.html
>
> which I like.
>
> + for create:
>
> http://foo.com/folder1/folder2/+/Document/
>
> to accsess a UI for adding a document. I actually, want
> the screen that collects the content type to be added to
> also collect the content id so you'd have:
>
> http://foo.com/folder1/folder2/+/Document=mydoc/
>
> I don't like options that add a path step, due to the
> way that mucks up relative references (and things like
> internal path computations). I don't mind in the case of
> +, because that's very specialized (I think) case.
>
> I'm beginning to like Guido's suggestion of using ++
> as a general namespace marker, as in:
>
> http://foo.com/folder/++etc++Services/
>
> So, here's a suggestion:
>
> 1. The generalized syntax is:
>
> ++namespace++name
>
> as in:
>
> http://foo.com/folder/++etc++Services/
>
> 2. For the creation framework:
>
> +/type
>
> is a non-english short-hand for:
>
> ++create++type
>
> For example:
>
> http://foo.com/folder1/folder2/+/Document=mydoc/
>
> is a non-english short-hand for:
>
> http://foo.com/folder1/folder2/++create++Document=mydoc/
>
> 3. For views:
>
> @@viewname
>
> is a non-english short-hand for:
>
> ++view++viewname
>
> For example:
>
> http://foo.com/folder/@@ManageRolesAndPermissions.html
>
> is a non-english short-hand for:
>
> http://foo.com/folder/++view++ManageRolesAndPermissions.html
>
> Thoughts?
>
> Jim
>
>
> --
> Jim Fulton mailto:jim@zope.com Python Powered!
> CTO (888) 344-4332 http://www.python.org
> Zope Corporation http://www.zope.com http://www.zope.org
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev
--
Craeg K Strong, General Partner
Ariel Partners LLC
http://www.arielpartners.com
voice 781-647-2425
fax 781-647-9690