Hi there Ian, > *That's* certainly not what I would propose. I'd rather take the > crappiest of the options (um... let's say > /edit?class=myapp.Articles?id=10) than multiple ways to access the > resource with the same meaning.
I didn't mean that would be something we had to do but merely that overall it was not such a problem as long as we were able to handle those URIs in only unique way. > > Reading that particular document, my impression is that he is saying > that URIs don't matter, that they are opaque strings, and their only > meaning is what you can do with them. They don't represent "resources", > only "potential actions", and if you read anything more into the strings > you are overstepping the abstractions of the web. Agreed. That was my statement too. My point was that TG URIs should not show the underlying bindery TG uses but they still need to make sense regarding their actual action on the resource. > > Some REST principles seem unattainable in this context as well, like the > fact we are strictly limited to the GET and POST verbs. This is why I > think ?action=edit is reasonable, as it is the verb and there's no real > positional location that implies verb. It's an inversion of the typical > URI of edit?id=10, where the path is the verb and the variables are the > noun. Again I agree and that's the way I go on my applications. > > Of course, a real set of actions would be more like: > > view: show a representation > editform: show a form to edit the item > save: save changes to an item > delete: delete an item > createform: show a form to create an item > create: actually create the given item > select: show several items (e.g., /articles/ typically means select all). > > Several of these should *absolutely not* be in the URI, specifically > "delete", "save", and "create". Now, you could conflate these with > other actions, e.g., editform and save (edit+GET=editform, > edit+POST=save), and createform and create, and some arbitrary action > and delete (maybe select or even view). But I don't think that's very > REST, if we're throwing about terms. Well yes and no. The problem here is that we can easily mix th what and how. edit+GET = editform is perfectly correct IMO from a REST POV since it means "fetch the resource with id=10" and its representation is then an HTML form. Again, I'd be pleased if TG could use the power of HTTP to handle its resources but it would mean for CP to be a bit more ready. It's where we go with 3.0 but it's not baked yet. - Sylvain ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
