Why Coldfusion REST API instead of ColdFusion normal CFC

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,

^ _ ^

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.

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-services-in-coldfusion.html

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-enhancements-in-coldfusion-11.html (CF11 changes)

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