Introducing RESTfulCF

52 visningar
Hoppa till det första olästa meddelandet

Tim Blair

oläst,
17 juli 2009 09:47:352009-07-17
till cfrest
Hello RESTafarians,

I thought I'd take the opportunity to introduce a new CF/REST project:
RESTfulCF; it's a framework for publishing a REST interface to a
ColdFusion
application.

The project is linked through from RIAForge, and the code is hosted on
GitHub:

http://restfulcf.riaforge.org/
http://github.com/timblair/restfulcf/tree/master

The framework has been extracted from some of my recent work on the
White
Label Dating (http://www.whitelabeldating.com/) platform. We needed
to be
able to provide a simple REST interface on top of our existing
ColdFusion
app for use on various key internal projects, including a new Ruby on
Rails
system, and a Javascript-based reporting dashboard. The framework is
currently in production use on the White Label Dating platform.

The basic principles of RESTfulCF are:

* Resources are implemented as components, with properties of the
resource
defined using <cfproperty> tags. onMissingMethod() is used to
provide
implicit setter/getter functions for those propertise;

* There are default representations which apply to every resources
(unless overridden within the resource component itself), which
means
writing a lot less code;

* Controllers are the "glue" that makes the system work: functions
are
defined to handle each type of request (read all resources, read
one
resource, create a new resource etc) that may be made of a
resource;

* Convention-over-configuration for defining routes: a single
function
call of addResource("world") will automatically map common URI
patterns
to a `Worlds` controller, for example `GET /worlds/:id` will be
mapped
to the `read` function.

"Why not use PowerNAP?", you may ask. Good question! I think the
work
Brian's put in to PowerNAP has resulted in an excellent framework, but
after reviewing our needs there were a few things that either didn't
sit
quite right with me, or that we just didn't need, such as Coldspring-
based
resources, per-resource authentication and the explicit separation of
resources from representations

In addition, a number of features that we required (for example:
default
representations, collection handling, Rails-isms for error reporting
and
attribute typing in XML representations) would have been difficult to
implement in PowerNAP.

In general, RESTfulCF has been designed to provide a lightweight
interface
sitting on top of an existing business logic layer, rather than to
provide
the whole application itself.

Your thoughts and comments would be greatly appreciated.

Thanks,

Tim.

--
Tim Blair
http://tim.bla.ir/

Tim Blair

oläst,
17 juli 2009 10:06:022009-07-17
till cfrest
*sigh*

And typically, Google Groups munges the introductory email and makes
me look like a slovenly fool.

(note to self: Groups wraps lines at 70 characters)

Sorry about that: let's try again.

------------------------------8<------------------------------

Hello RESTafarians,

I thought I'd take the opportunity to introduce a new CF/REST project:
RESTfulCF; it's a framework for publishing a REST interface to a
ColdFusion application.

The project is linked through from RIAForge, and the code is hosted on
GitHub:

http://restfulcf.riaforge.org/
http://github.com/timblair/restfulcf/tree/master

The framework has been extracted from some of my recent work on the
White Label Dating (http://www.whitelabeldating.com/) platform. We
needed to be able to provide a simple REST interface on top of our
existing ColdFusion app for use on various key internal projects,
including a new Ruby on Rails system, and a Javascript-based reporting
dashboard. The framework is currently in production use on the White
Label Dating platform.

The basic principles of RESTfulCF are:

* Resources are implemented as components, with properties of the
resource defined using <cfproperty> tags. onMissingMethod() is used
to provide implicit setter/getter functions for those properties;

* There are default representations which apply to every resources
(unless overridden within the resource component itself), which
means writing a lot less code;

* Controllers are the "glue" that makes the system work: functions are
defined to handle each type of request (read all resources, read one
resource, create a new resource etc) that may be made of a resource;

* Convention-over-configuration for defining routes: a single function
call of addResource("world") will automatically map common URI
patterns to a `Worlds` controller, for example `GET /worlds/:id`
will be mapped to the `read` function.

"Why not use PowerNAP?", you may ask. Good question! I think the
work Brian's put in to PowerNAP has resulted in an excellent
framework, but after reviewing our needs there were a few things that
either didn't sit quite right with me, or that we just didn't need,
such as Coldspring-based resources, per-resource authentication and

Brian G

oläst,
19 juli 2009 19:01:272009-07-19
till cfrest

Tim,

Very cool - I will have to take a look at this! Do you have any
caching or debugging techniques that are working well for you? Those
are two things my (powernap-powered) REST API are missing that Brian
Carr and I have talked about adding. The more CF+REST stuff out there
the better in my opinion, that means more people are building REST
APIs. :)


Brian

Tim Blair

oläst,
20 juli 2009 04:41:132009-07-20
till cfr...@googlegroups.com
Hi Brian,

> Very cool - I will have to take a look at this!

If you have any questions or comments at all, please fire them over.

> Do you have any caching or debugging techniques that are
> working well for you?

We actually have both running on our production API at White Label
Dating - extracting it all and adding to RESTfulCF is already on the
to-do list:

- we're using a memcached-based cache for certain responses (GET
requests only), but I also have a simpler Application-scope cache
that can be used;

- for debugging purposes, the `Response` object that's returned from
the endpoint custom tag can be used to access any of the request
and routing data, which we use (with CFLogger:
http://cflogger.riaforge.org/) to log all requests in development,
and errors in production;

- the WLD API also handles internal ColdFusion errors (and returns
the information as part of the `Response`) and again logs these to
permit easier debugging.

Is this the sort of thing you meant?

Svara alla
Svara författaren
Vidarebefordra
0 nya meddelanden