Why Coldfusion REST API instead of ColdFusion normal CFC

[cfrbt]

Could anyone please help me understand the need of ColdFusion (CF) REST API when actually ColdFusion remote CFC methods can implement the functionality ? 

It is true that CF REST API needs to be registered and uses / implements HTTP methods. However, still intended functionality / logic can be implemented in a remote CFC method which is accessible through a URI.

The bottom line is any functionality / logics can be implemented and access over http in both the cases, why do we really need CF REST API ?

[Charlie Arehart]

That's a reasonable question, cfrbt, why use it over just implementing the same capabilities via remote CFC methods? I'll take a crack at it, but others may do a better and more succinct job. 🙂

First, as you may already know, REST is indeed about a lot more than just that simply "access to functionality over http". And your question could be asked by a developer in any web app server language which might offer REST support, in addition to what may be possible via the language itself.

And FWIW, there's a discussion on this page on Oracle from a Java perspective:

https://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html

And the following CF doc on CF REST itself starts out pointing to that link for perspective. If you've not read the CF docs on REST, you'll certainly see what else Adobe's implementaiton of REST offers:

https://helpx.adobe.com/coldfusion/developing-applications/changes-in-coldfusion/restful-web-service...

And for a still more elaborated introduction to them, from a Java rather than a CF perspective (where a Java developer could also do much without leverating the dedicated REST features added in Java), see this tutorial:

https://www.codeproject.com/Articles/5247280/Guide-to-Building-a-Good-REST-API-in-10-Days

Of course, I realize you didn't ask "where can I learn more about REST". My point in offering these links is simply to suggest that the question, "why bother, vs just writing CFCs" could become more clear, the more you learn about what the REST functionality offers. 

In fact, you could also gain a lot of perspective as well from the substantial docs for the Taffy framework, which had been created by Adam Tuttle to offer a REST framework for CFML before Adobe added REST in CF10:
http://docs.taffy.io/3.2.0

Perhaps even better (to answer your question), note also that Adam had subsequently created a book, called "REST Assured", available for purchase as an ebook at https://restassuredbook.com/. Even just reading his front page, you can tell that he wrote it to help people who felt that there was a lot they found else about REST that left them either frustrated or unimpressed. Perhaps his resource will help you. 

But if you may still need to see more, and if you want to hear more (not about CFML) on how REST is distinguished (and reasons it's favored) over not using it, here's one more. While it focuses on REST vs RPC, I think you'll find some parallels in your question about CFML:

https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/

Finally, if you may need any further justification that developing apps with CF's REST feature is still seen as a preferred way over rolling your own equivalent just leveraging remote CFC methods, I'll note that there have been features added to CFs REST support in each recent release:

https://helpx.adobe.com/coldfusion/using/rest-enhancements-coldfusion.html  (2018 changes, many)  

https://helpx.adobe.com/coldfusion/using/swagger-document-generation.html (2016 changes)

https://helpx.adobe.com/coldfusion/developing-applications/developing-cfml-applications/rest-enhance... (CF11 changes)

Hope that's helpful. If not, let's see if anyone else may offer better info for you.

[cfrbt]

I had already gone through the adobe links on REST API. Actually, I had just got curious comparing with the time when I was using remote CFC methods (along with jquery) to get JSON responses for GET/ POST requests.

Thank you so much for providing ocean of information.

[Charlie Arehart]

Glad to help, and the thread was enlightening in many ways.

One other thought I'd share is that considering whether to go the REST route (vs rolling your own) is a lot like the classic debate about  using a CFML framework vs rolling your own. REST really is a framework for web API design, with conventions and features that you get if you go with that flow. But just as many forego the benefits of frameworks in CFML (for any of many reasons), you can see here there are some who would forego using REST for their reasons.

And sure, to a degree it's simply about preference, as Wolfshade said. My point in sharing the "ocean of info" was to show that there is indeed a LOT behind REST--and more than just what Adobe has enabled, and they do keep enhancing it. I just wanted to help anyone contemplating it to make an informed decision, but folks are indeed free to make their own choices. 🙂 

[BKBK]

cfrbt: ... why do we really need CF REST API ...when actually ColdFusion remote CFC methods can implement the functionality ? 

With regard to your question, Charlie has mentioned what I believe to be the 2 key points. Firstly, that REST is more than just funtionality over HTTP. Secondly, that REST transcends the programming language - be it Java, ASP.NET, PHP, Ruby, Python or ColdFusion - even if the language offers customized resources to implement requests via HTTP.

The links Charlie provides cover a lot of ground on the subject of REST. At the risk of repetition, let me add a few lines here, as lead-up.

Representational State Transfer (REST) is a style of architecture. That is, of software design. As such, REST doesn't really pertain to software implementation. Implementation tools such as objects, CFCs, components, classes, libraries and so forth, are considerations that you make besides, usually following, the software design phase. Being design, REST is something you do before you write a single line of code. This is analogous to the architecture of a building. Traditionally, architecture has more to do with pencil-and-paper designs and less to do with mortar, bricks and walls.

That was the lead-up. Now, on to the relevance of the two key points to your question why.

REST is more that just HTTP. REST is design. Design -  in any field of art, science or engineering - involves solving a problem within a given number of constraints. It just happens that REST uses the HTTP protocol as a way to handle some of the constraints. So, REST transcends any programming language, even if the language offers customized resources to implement requests via HTTP.

What then is the problem? And what are the constraints?

In software the problem is usually to build an efficient, responsive and scalable service that will stand the test of time and deliver the service-provider, as well as the client, value for money. You have to solve that problem within certain constraints. The usual constraints are:

1. separation of concerns between client and service
2. efficiency in client-server communication
3. maintaining client state
4. independent evolution of client and service over time

REST is just one design solution to the problem. It takes the constraints into account in the following ways, for example:

1. separation of concerns between client and service

Use client-server architecture to separate the concerns of the client from those of the service.

2. efficiency in client-server communication

Use caching to avoid unnecessary interaction; use a layered architecture to separate a third party, such as a proxy, load-balancer or security-authenticator, from the client-server interaction.

3. maintaining client state

The constraint of separation of client-server concerns implies that, in between requests, the server is not allowed to store the client context. REST solves this by making use of the HTTP protocol. That is because HTTP is stateless. And this is one point in which HTTP enters the REST story.

4. independent evolution of client and service over time

For the client and the service to be able to evolve independently, the design of the one has to be decoupled from that of the other. REST achieves this by basing the design of the client and server ensemble on resources. 

Thus, a service consists of resources, each having a unique Uniform Resource Identifier (URI). There are specific rules on how to construct URIs that will satisfy the other constraints. If the service is a Library API, for example, the resources will be represented by unique URIs for each of the Authors, Books, Borrowers, and so on.

The client requests the URI by means of one of the HTTP methods, commonly, Get, Post, Put, Delete or Patch.  

Typically, the server's response to a URI must ensure that, at any time, the client holds a representation of a resource that includes the resource's media type, any necessary metadata, as well as the hyperlinks that enable the client to dynamically discover every related or follow-up resources needed.

In conclusion, to implement REST means to begin with an API design that satisfies the RESTful constraints. It is a way to transform a complex design problem into a simpler, more manageable one. However, REST is, in my opinion, not as easy or as simple as some claim it to be. Otherwise it wouldn't have earned Roy Fielding a Ph.D.

REST may be quite a challenging balancing act but, if done properly, the resulting API will save you tons of buck$. Especially in the long run. 

I hope I have been able to convince you that REST is more besides a remote CFC request via HTTP.

[Charlie Arehart]

Good points on it being more about design, etc. Those were indeed conveyed in the resources, but you're right that it could be better to draw out key poitns, especially as yours seem to be coming from direct experience, which is great.

Now we shall see where cfrbt may want to take things. 🙂

[cfrbt]

Thank you very much for providing a design perspective of REST APIs and its capabilities. Really Awesome!!.

[WolfShade]

I, too, have been curious as to what all the hub-bub is about REST API and why it's supposedly better than RPC.  After reading the remarks, here, and glancing at one of the links provided, I have come to the realization that it's really just a matter of preference.  Some people like CF because it is so robust; some people hate CF because it's too HTML-like and not perl-like.  Preference.

Personally, I prefer RPC.  Simple, straight-forward.  I'm also the kind of person that doesn't use GET for anything I don't have to use GET for; I much prefer POST.  It's just more 'comfortable', to me.

Thank you, guys, for the links and the explanations.  I learned something new, today, and that's always a good thing.

V/r,

^ _ ^

[BKBK]

WolfShade: "...what all the hub-bub is about REST API and why it's supposedly better than RPC."

I cannot see any grounds for comparing REST to RPC; let alone any benefit. Forget the fact that RPC is forty years old and REST twenty.

REST is an architectural style. Hence, you use it to solve a design problem. As such, it is global as far as the application is concerned. Everything about REST is concerned with design: how you design for separation of concerns, client-server interaction, client state and how client and server will each handle change.

Whereas RPC is essentially a communications protocol. As such, it has the much narrower scope of a request-response cycle. The client calls a stub, marshalls and requests; the server unmarshalls, invokes and responds. In traditional RPC the client and the server are therefore bound together. The client waits until it gets an answer from the server before moving on. That, in particular, is the kind of tight coupling that REST seeks to avoid.

Java illustrates the difference in scope between the two. Java's implementation of RPC, the Java Remote Method Invocation, is just an API. Compare that to JAX-RS, a Java implementation of REST, which is an Enterprise API Specification.

This answer is added to clarify. Comparing REST with RPC has little or no practical relevance. They are two different things. If you're happy with RPC then, by all means, continue to use it.