beginner taffy questions

92 views
Skip to first unread message

Brian FitzGerald

unread,
Feb 19, 2014, 11:26:33 AM2/19/14
to taffy...@googlegroups.com
Hey there,

Taffy looks really cool! I have never written a restful api before and I have couple beginner questions.

Question 1)

Using taffy to manage my service layer, will I be able to call methods on my components from the server as well as the client? Certainly one wouldn't want to have two separate service layers, right? So if I call from a js front end: "/students/235423" I get back a nice json response, but if I call StudentService.getStudent(id) from a cfml page, the same method would be run but instead of json, a native cf response (object, query, etc.) would be returned instead.

In my mind, this is similar to calling method on a normal cfc with access="remote" and specifying the returntype as json or not.

Is this how Taffy works or am I way off the mark here?

==================================================

Question 2)

Sort of related to question 1... not looking for an in depth answer here, but a thought or two if someone is willing to share.

Why write a restful api at all? Since cfml by default supports access="remote" which can return both json and cf data types (based on the returnformat specified), why bother with all the extra complexities of making it "restful"? Is the benefit simply clean, intelligible urls, or is there much more to it that I am missing?

Told you they were beginner questions!

Thanks a lot for your insight,

Brian

Matt Quackenbush

unread,
Feb 19, 2014, 11:45:39 AM2/19/14
to taffy...@googlegroups.com
Hopefully someone will come along shortly with a more in-depth response (sorry, headed to a meeting!), but I wanted to quickly address your questions.

1) You would not use Taffy to manage your service layer. Rather, Taffy could be your only service layer or it could be one of a couple or three service layers. That is, you can use Taffy to provide RESTful services to certain consumers while another application (or any number of them) could / would use a different service layer. Each service layer that you might have (one or more) should, however, rely *on the same model*.

So, think of it this way. Your model layer has a particular API that its consumers (service layers, generally) interact with. Those service layers then have their own API that they expose to various consumers. This allows your app to grow infinitely (in theory), providing a different interface as required.

2) Definitely much more to a RESTful API than clean, intelligible URLs. Perhaps this will be a good overview for you?  http://en.wikipedia.org/wiki/Representational_state_transfer

HTH




--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Adam Tuttle

unread,
Feb 19, 2014, 11:53:02 AM2/19/14
to taffy...@googlegroups.com
Hey Brian,

I think Matt's response is right, but maybe I can clarify a little bit.

Q1: That's just not how Taffy was designed. It's meant to be a thin layer that makes your service layer into a restful API. If you choose to combine the two, that's perfectly fine and functional, but as you're noting, means you can't use those resources from the rest of your app. If you want that reusability, make a service layer that is a set of CFC's and functions that do what you want, then use those CFCs in both your app and in your Taffy API.

Taffy can work directly with Bean Factories like ColdSpring and DI/1 if you want to use them. Or just manage it yourself. Taffy's strength is managing the bits of interfacing with the HTTP request/response in a clean RESTful manner.

Q2: That's mostly a philosophical question. The short answer is because everyone else does REST. That might sound a little "conformist" or something, but think about it: Anyone that's consumed any REST API built with any other technology should be able to use that knowledge to work with your API. Contrast that with using CF's built in ability to return JSON from remote-accessible methods, and sure, the functionality is almost the same... but then you've got to teach developers what the URLs are and provide a bunch of documentation and if they don't come from a CFML background they're probably going to find the whole think awkward and strange.

It's the same reason you don't apply all of your styling rules with JavaScript. Just because you can doesn't mean you should. :)

Adam

Brian FitzGerald

unread,
Feb 19, 2014, 2:04:08 PM2/19/14
to taffy...@googlegroups.com
Matt and Adam,

Your responses are much appreciated! You've both definitely helped me get all this a little straighter in my mind.

"It's meant to be a thin layer that makes your service layer into a restful API." Got it.

Thanks,
Brian

Adam Tuttle

unread,
Feb 19, 2014, 3:12:18 PM2/19/14
to taffy...@googlegroups.com
Glad to help. Welcome aboard. Keep asking if you have any more questions. :)

Adam


--
Reply all
Reply to author
Forward
0 new messages