Can REST be used instead of rewriting URLs in CF10?

Question

Can CF10's REST support be used to replace the use of Rewrite / ModRewrite URLs for SEO-friendly URLs? Write a thin layer that defines the GET and POST method, and <cfinclude> on the correct page?

Or did he put the server on the server too much and would rather leave it on the web server?

Once in CFML it would be much easier to control and maintain the version.

thanks

Answer 1

@Henry REST is not a replacement for rewriting URLs.

First of all, REST URLs are formatted.

http: // localhost: 8500 / rest / App_Name / Rest_Path

"Rest" part is required. If you want to change the "rest", you can change it in the web.xml file (change the URL mapping).

App_Name is optional. The server may have a default application. For default applications, you do not need to specify an AppName. To access other (non-standard) leisure applications, you must specify AppName. You can make the default application on the administrator’s leisure service registration page.

Rest_Path defines a CFC and a function in CFC that must be called when an HTTP call is made.

If this URL format is acceptable, then the URL of these formats can be mapped to a specific function in CFC. When ever an HTTP call is made to a URL, the corresponding CFFunction will be called. Using REST, you get access to the function in CFC. Therefore, it is not possible to access CFC or CFM. But in a function, you can implement whatever you want (for example, call CFC, call another CFM, etc.).

Does the answer to your question?

Thanks Paul

Answer 2

If I understand what you are saying (and maybe not), would you create a handler that would intercept the request, parse the variables, and then request the appropriate page through REST? If this is what you mean, then I’m not sure that I will follow what you will benefit from it. REST (in general) is rather a universal HTTP API for getting methods - not so much the page / content paradigm (I think I suppose it could be).

If you want to use CF as your SEO rewrite URL handler, you can do it now. To use the IIS example, you can create a "custom 404" handler, a CFM page that receives all requests that are not bound to a specific document. The handler teases the variables by parsing the URL, then "includes" the correct code or cfm page. This is similar to what you want - but it is not really REST.

Perhaps you are thinking of making some kind of CFHTTP call where you grab the content you need by building a query string from a URL. Therefore, if someone loads a URL, for example:

blah.com/productid/550

You can write code like this -

 <cfhttp url="http://blah.com/index.cfm?#listfirst(cgi.script_name,'/')#=#listlast(cgi.script_name,'/')#"/> <cfoutput>#cfhttp.filecontent#</cfoutput> 

Although this will be a trick, you would be better off using cfinclude rather than this approach. An approach like the one above actually generates an additional stream for each request - one stream for the browser request and another for the cfhttp request.

Finally, I would say that the Rewrite URL (in apache or IIS) is more efficient and more "conditional", and therefore, probably the best choice overall.

Answer 3

Even if this could be done, I would say that he is co-opting the wrong tool to do the wrong job. URL rewriting is the job of the web server, not the CF server, and the web server will be much better than CF. The CF REST interface is for creating APIs, not for rewriting URLs.

If you needed to handle URL rewriting with CF, then using a 404 handler or onMissingTemplate () handler would be better suited here, wouldn't it? At least you are using a tool designed for the job (if not the best).

As for version control ... a .htaccess file is just a text file, like a CFML file. I did not look too closely at the IIS rewrite module, but can I use a text file to configure / save its rewrite? Obviously, Apache can, and we use the Helicon ISAPI Rewrite module, which uses a .htaccess file compatible with mod_rewrite.

It seems to me that you are trying to simplify the work of the developer, using an approach that will punish performance. “Making life easier for a developer” should never be the basis for compromising a production environment (obviously IMO).