Skip to main content

Posts

Showing posts with the label REST

AngularJS - Resolving data services before instantiating the Controller and Template

I have been working on an Angular application for sometime now and I have started to like this approach to client-side development. It's a different approach when compared to developing applications using Backbone and Require. I was looking at routing in Angular and came across the 'resolve' property which can be used to resolve services before instantiating the Controller and it's corresponding template i.e. the domain models that are required for the View components are resolved first.

Backbone.js - Creating a RESTful CRUD application

I've been trying to build a CRUD application using Backbone.js and was able to retrieve a set of records into a collection using the fetch method . To perform other operations i.e. Create, Update and Delete I could always invoke Backbone.sync but I was exploring on the lines where this is performed implicitly. The fetch method sends an implicit GET request on url specified in the Collection, similarly I was looking for other methods that allow you to send POST, PUT and DELETE requests to the url. While I was building this application, I did come across a condition where Backbone was not sending a request. I was finally able to figure out as to why that happened and then it was a simple fix in my Backbone application as well as in the REST service.

Backbone.js - Parsing the response from the server

From past few weeks, I've been learning Backbone.js in great detail and I think it's a great framework that helps you modularize your code easily. Last week I wrote about ' Model validation in constructor ' and then started to look at Collections in Backbone. The Model objects can be viewed as table rows and the Collection as a table. A Collection can declare the model property and indicate what kind of data it will hold. I was looking into ways in which a Collection can be populated by fetching the model data from the server. One way to do that is to ask the Model to fetch the data and then add the response to the Collection . The other way of doing this is to fetch the Collection data directly from the server i.e. instead of defining a Model you create a Collection by fetching the data from the server. Usually when you send a request to the server, the response data is essentially a collection of objects. In this case you really don't need a Model to be defined.

ColdFusion 10: Working with REST Sub-resources

In REST everything is treated as a resource and each resource is associated with a URI from which it can be accessed. As mentioned in my series of posts on REST ; in ColdFusion methods defined in a CFC are made RESTful by adding the attributes httpmethod and restpath. The restpath value specified in the method can then be used to access the resource. Although this would serve the given purpose, it would be a good idea to have a root resource resolve a generic URL and then have different methods that resolve other path of the URL.

ColdFusion 10: Making REST Pathparams optional

I was working on creating a CRUD application with REST and wanted to retrieve records with a GET request. The GET request would contain the ARTID for which the record has to be retrieved in the URL itself. To do this I had added an argument to the method implementing the GET request with ‘restargsource’ attribute set to path. The URL would be of the form: http://localhost:8500/rest/restapp/artService/getart/1 However, in another scenario I wanted to retrieve all the records from the ART table when there is no ARTID specified in the URI i.e. with the URL: http://localhost:8500/rest/restapp/artService/getart/ PathParams are always required and if they’re not specified then a ‘404 Not found’ error would be thrown. I thought of adding another method to handle this GET request with no PathParams. But, it would have made my code look clumsy and semantically not correct. However, I was able resolve this by providing a regular expression for the PathParam argument.

ColdFusion 10: REST settings in Application.cfc

There are a couple of variables that have been introduced in Application.cfc which are REST specific. These are this.restsettings.cfclocation and this.restsettings.skipCFCWithError . If you have a list of directories containing REST enabled CFCs then you can specify the same in the variable this.restsettings.cfclocation. At the time of registration, the specified directories and its subdirectories will be scanned for REST enabled CFCs and then deployed. If any of these CFCs contain compilation errors then an error is thrown and the registration would fail. To tackle this another variable this.restsettings.skipCFCWithError is provided. When set to true, the CFCs with compilation errors would be skipped. Only those without any compilation errors would be deployed successfully.

ColdFusion 10: Returning Complex data from a REST service

There are various complex types in ColdFusion – Array, Struct, Query. When a REST service in ColdFusion returns one of these complex types, it has to be serialized to either JSON or XML format. As explained in my previous post , the HTTP protocol can be used in content type negotiation. You can specify the desired content type either by specifying it at the end of the URL or in the Accept header of HTTP request. In this post, I’ll explain the format in which the complex types are returned from a ColdFusion REST service.

ColdFusion 10: HTTP Content Negotiation + REST– Part 2

Following with my previous post on how content negotiation between the client and server help in invoking an appropriate REST service. In this post I’ll explain how one can specify multiple mime types in the request header and also the quality factor that enables server to decide which mime type to serve for the incoming request. The client sends a HTTP request to the Server along with several headers, one of them is the Accept header. The Accept header can contain a list of mime types that the client (user agent) is willing to process. These mime types are separated by a comma and may optionally be combined with the quality factor. A CFC can contain several methods with produces attribute set to a specific mime type. The Accept header may contain several mime types: text/html, text/plain, application/xml, application/json, */* Server would parse the Accept header and will search for a REST service that matches the mime type specified first in the Accept header list. In this cas

ColdFusion 10: Using HTTP Content Negotiation to invoke a REST service

The HTTP protocol provides a Content negotiation mechanism using which different formats of the document can be served using the same URI. For example, a JavaScript application can request the content in JSON format and an external system say a Java client can request for the same content in XML format. Here the clients need to specify the content format in the Accept attribute of the HTTP request. The REST service can specify the format in which the data will be returned to the client in ‘produces’ attribute.

ColdFusion 10: Accessing a REST service without specifying the Application name or Service mapping in URL

In my previous post, I’d explained how REST services can be created, published and accessed in ColdFusion 10 . Andy , asked me “Is there any way to avoid having the /rest/restapp/ in the URL?”. In short Yes. ‘rest’ in the URL lets the ColdFusion Server know that the incoming request is for a REST service. As mentioned in my previous post, you can update the servlet mapping defined in web.xml located at cfusion_home\wwwroot\WEB-INF directory. But it can't be avoided. Coming to the ‘restapp’ in the URL which indicates the Application name or the Servlet mapping. It can be removed from the URL by placing the CFCs in a default directory. While registering a REST service in the ColdFusion Administrator, there is an option to set the service as a default service, meaning all the CFCs placed in the directory would not require the Application name or Service mapping to be provided in the URL.

ColdFusion 10: RESTful WebServices in ColdFusion - Introduction

In ColdFusion 10, support for creating and publishing REST services has been added. The ColdFusion components can now be made available as REST services and these services can be consumed by various clients. REST stands for Representational State Transfer. It is an architectural style which is based on web standards and HTTP protocol. The idea here is to use HTTP protocol instead of complex mechanisms such as CORBA, RPC or SOAP to connect between the machines. In fact, the World Wide Web which is based on HTTP can be viewed as a REST based architecture.