Collections and Members in the same CFC... "mind blown!" or "OMG WANT!" ?

[Adam Tuttle]

Denny, the primary maintainer of CFEclipse (among other notable things...) made a change to his copy of Taffy that I wanted to throw out to you all and see what you think.

https://github.com/denuno/Taffy/commit/de8986d8b57db2aa11c800031bb3157cfe2b9fdb

If I'm reading the code and playing it out in my head correctly, this change allows the last element of an URI, if it's a token, to be optional. So you could have the following component:

<cfcomponent extends="taffy.core.resource" taffy:uri="/students/{studentId}"></cfcomponent>

And it would be selected for BOTH URLs:

/students/

/students/12

As of right now, I'm sort of in the "mind blown" camp, because the separation of members and collections into different resources was one of the fundamental concepts I had when creating Taffy -- it's hard for me to see past it. But is it just dogma? I don't know. That's where you come in.

Granted, it's an extremely simple change, and if it doesn't break anything (testing required...) then I don't see why we couldn't go ahead and support it.

But what do you folks think about it? Does the concept interest you?

Adam

[AJ Mercer]

goes that mean, for example, the GET method would need to test for studentid and exists do something different?

--

AJ Mercer
<webonix:net strength="Industrial" /> | <webonix:org community="Open" />
http://twitter.com/webonix

Railo Community Manager

[Adam Tuttle]

I think so, yeah.

[AJ Mercer]

Hmmm - bit of a down side for me.

Maybe if CF had function signatures

so you could have two GET methods, one with a argument of studentid 

it would work well.

On the fence about this one at the moment.

Would need to hear some advantages for it.

[Barney Boisvert]

I'm of the opinion that you should have

/students
/student/{id}

So you shouldn't want to have the same URL pattern for both.  Yes, with Taffy you'd need and extra CFC, but it's going to be like three lines long (delegating to your model), so is it really much of a burden?  In your model you can have getStudentList() and getStudent(id) right next to each other.

cheers,
barneyb

--
Barney Boisvert
bboi...@gmail.com
http://www.barneyb.com/

[Matt Gersting]

I'm with Barney on this one.  Very much seems to be the standard.

[denstar]

I guess it depends on who (or what) your consumers are.

Here's an example from wikipedia:

http://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_services

http://example.com/resources/ (collection)

http://example.com/resources/item17 (item)

Not that wikipedia is some kind of authority.  :)

But I've worked a good bit with REST for a while (dojo has *awesome* support for it, BTW), and it's pretty popular to use a single endpoint/target vs. one for collections and one for items.

As a human, people/ for collections and person/1 for items seems more natural, but to a computer, that's a needless complication.  It makes coding things harder, yadda yadda.  Kinda kills the whole drill-down idea.

Although you can use a web browser to explore RESTful stuff, it's not (IMHO;]) /really/ intended to be explored that way.  Take, for instance, this, which I was looking at not too long ago:

http://stackoverflow.com/questions/924472/paging-in-a-rest-collection

Anyways, I'm firmly in the single endpoint camp, but that's kinda beside the question-- should you have a separate component for aggregates/collections?  To me, this seems to relate to the (kinda mixed-up) gateway + DAO pattern that was popular with CFML a few years back.  For kicks, here's another SO link (not the best example, but whatever- it popped up first):

http://stackoverflow.com/questions/2810020/need-some-clarification-with-patterns-dao-x-gateway

It might relate to the high cost of instantiating objects in CFML at the time... but anyway, if you work with arrays, there's not much difference between an array with a single element and one with many.  At least not the huge difference you'd see with the idea of having two ways to get at your stuff (one for collections of objects and one for objects), which return things *differently* depending on which you use.

Now, I'm not saying one /shouldn't/ organize one's code in X way-- perhaps keeping your aggregate functions in their own deal is best for you, ya know?  And perhaps not.  I think it depends a great deal on what you're doing, what yer working with, etcetera etcetera.

Which brings me to why I think this should be "allowed" in Taffy:  One /could/ be using taffy as a facade of sorts, and not mind one whit having

if(itemId != "") {

do single item collection stuff;

} else {

do multiple item collection stuff;

}

Whereas if doing something like:

if(itemId != "") {

all kinds of crazy stuff

that is not clear and

kind of sucks

} else {

lots of other things that 

also kind of suck

and are not encapsulated

}

^-- Totally contrived and not very expressive of what I mean, but fsck it. :)

Ennywho, I'm not trying to push Tao X, I'm just saying that sometimes The Way might be a single component, and since that doesn't stop anyone from using two, why not allow it?  Are we certain that this conformity is always (or even mostly) in the best interest of code?  I honestly don't know, and I change my mind from time to time, so YMMV, but, to sum it up...

FREEDOM!  =]

:DeN

-- 

Ancient recipients of instant news probably couldn't do very much about it, for instance. Xerxes would still need three months to get his army together, and he might not get home for years.
Peter Singer 

[AJ Mercer]

Well, if as Jack says to Liz (30 Rock), "you can have it all",

and it is easy to implement, I think it would be a good addition to Taffy.

[AJ Mercer]

I am not a fan of student & students for end points.

I think a URL should be hackable, that is, remove late part of it and it will still work.

eg /student/17 -> /student

What happens here?

[denstar]

On 12/4/11 3:14 PM, AJ Mercer wrote:
> Well, if as Jack says to Liz (30 Rock), "you can have it all",
> and it is easy to implement, I think it would be a good addition to Taffy.

That show, um, rocks! heh. :)

It's a two-line tweak, and then the URIs can look like this:

/{entity}/?{entityId}?/?

Of course, this begs the question of sub-entities (for lack of a better
term ATM), and when this approach is actually optimal. Ex:

#Entity.cfc (?)
/{entity}/?{entityId}?/?{subentity}?/?{subentityId}?/?

VERSUS:
#Person.cfc
/person/?{personId}?/?

#PersonAddress.cfc
/person/{personId}/address/?{addressId}?/?

To me it seems to depend a *lot* on what you are doing. Do you already
have an API that you're just wrapping with RESTfulness? Are you maybe
making a dead-simple RESTCRUD type of deal for ORM entities? ;)p

Bleh. Besides the gory examples, it *can* be optimal, as look at what
you'd have to do as it stands:

#People.cfc
/person/?
#Person.cfc
/person/{personId}/?
#PersonAddresses
/person/{personId}/address/?
#PersonAddress
/person/address/{addressId}

(or some such) Even if you've got things encapsulated to where a single
Person.cfc gets the "person" job done (same for address). (Don't get me
started on if the end slash should be meaningful or not.)

Eh. People vs. person probably isn't as big a deal as post vs. put:

http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/

(that was an article that made an impression on me when I started RESTing)

But I digress... =]

:den

--
As we realize that more and more things have global impact, I think
we're going to get people increasingly wanting to get away from a purely
national interest.
Peter Singer

[Adam Tuttle]

I agree that you should not separate "students" and "student", but even _always_ doing "students" you can still work pretty intuitively with two components. Not to get all Charlie Arehart on ya, but I just want to make sure that's clear. The two components are _NOT_ to support "students" vs "student", they are to separate cases where you're dealing with collections and cases where you're dealing with members (the two sides of your IF statement examples...)

Aside from that, it sounds like a philosophical disagreement, which is, nearly by definition, unresolvable. ;)

Adam

[denstar]

On 12/4/11 5:35 PM, Adam Tuttle wrote:
> I agree that you should not separate "students" and "student", but even
> _always_ doing "students" you can still work pretty intuitively with two
> components. Not to get all Charlie Arehart on ya, but I just want to
> make sure that's clear. The two components are _NOT_ to support
> "students" vs "student", they are to separate cases where you're dealing
> with collections and cases where you're dealing with members (the two
> sides of your IF statement examples...)

LOL! CAreharted, yo! :)

Yeah, I focused a lot on plural(s) but I guess what I was thinking of is
if you've got a student service, which handles the many and the one, and
you just want a StudentRESTService vs. a StudentRESTService and
StudentRESTServiceCollection type of deal.

It all depends on what yer doing, what you've got to work with, etc., I
think.

> Aside from that, it sounds like a philosophical disagreement, which is,
> nearly by definition, unresolvable. ;)

Maybe... an agnostic, logically, has a better chance than an [a]theist,
if we were to posit the proof/negation of God or an afterlife or some
such, neh? Better odds covering both than taking a side... ;))

*evil grin*

:Denny

--
Bush doesn't present himself as a realpolitik politician.
Peter Singer

[Cameron Childress]

I've been casually watching this group, but haven't read all the threads, or even most of them, so admittedly some of this may be out of context.  Having said that, I'll toss one comment out regarding plurals and singulars on entities.

If you look to ORM as a pattern, consider calls like entityLoad(Entity), which loads many records, vs entityLoad(Entity,key,true), which loads a single item.  I know that REST is not ORM, but I do think that there are things to be learned from comparing the patterns used.  At the least this is somewhat of a precedent that this sort of pattern may not only be acceptable, but also perhaps unexpectedly familiar.

-Cameron

-- 
Cameron Childress
--
p:   678.637.5072

im: cameroncf

facebook | twitter | google+