Building REST APIs
Overview
REST APIs are a popular and easy way to add HTTP endpoints to your web applications to act as web services for third parties or even other internal systems. REST is simpler and requires less verbosity and overhead than other protocols such as SOAP or XML-RPC.
Creating a fully-featured REST API is easy with the ColdBox Platform. Everything you need for creating routes, working with headers, basic auth, massaging data, and enforcing security comes out of the box. We even have several application templates just for REST, so you can use CommandBox to create your first RESTFul app:
You will then see the following JSON output:
The rest
template is a basic REST template that does not rely on modules or versioning. If you would like to add versioning and HMVC modularity use the rest-hmvc
template. You can also find a full demo here: https://github.com/lmajano/hmvc-presso-demo
Quick Reference Card
Below you can download our quick reference card on RESTFul APIs
Introduction To REST
REST stands for Representational State Transfer and builds upon the basic idea that data is represented as resources and accessed via a URI, or unique address. An HTTP client (such as a browser, or the CFHTTP
tag) can send requests to a URI to interact with it. The HTTP verb (GET, POST, etc) sent in the header of the request tells the server how the client wants to interact with that resource.
As far as how your data is formatted or how you implement security is left up to you. REST is less prescriptive than other standards such as SOAP (which uses tons of heavy XML and strictly-typed parameters). This makes it more natural to understand and easier to test and debug.
Defining Resources
A REST API can define its resources on its own domain (https://api.example.com
), or after a static placeholder that differentiates it from the rest of the app (https://www.example.com/api/
). We'll use the latter for these examples.
Please note that we have an extensive Routing mechanism. Please check out our routing sections of the docs.
Let's consider a resource we need to represent called user
. Resources should usually be nouns. If you have a verb in your URL, you're probably doing it wrong.
Hint It is also important to note that REST is a style of URL architecture not a mandate, so it is an open avenue of sorts. However, you must stay true to its concepts of resources and usage of the HTTP verbs.
Here are a few pointers when using the HTTP verbs:
GET /api/user
will return a representation of all the users. It is permissible to use a query string to control pagination or filtering.POST /api/user/
will create a new userGET /api/user/53
will return a representation of user 53PUT /api/user/53
will update user 53DELETE /api/user/53
will delete user 53
GET, PUT, and DELETE methods should be idempotent which means repeated requests to the same URI don't do anything. Repeated POST calls however, would create multiple users.
In ColdBox, the easiest way to represent our /api/user
resource is to create a handler called user.cfc
in the /handlers/api/
directory. In this instance, ColdBox will consider the api
to be a handler package. You can leverage CommandBox for this:
Hint This command will create all the necessary files for you and even the integration tests for you.
Here in my handler, I have stubbed out actions for each of the operations I need to perform against my user resource.
/handlers/api/user.cfc
Defining URL Routes
Now that we have this skeleton in place to represent our user resource, let's move on to show how you can have full control of the URL as well as mapping HTTP verbs to specific handler actions.
The default route for our user.cfc
handler is /api/user
, but what if we want the resource in the URL to be completely different than the handler name convention? To do this, use the /config/Router.cfc.
file to declare URL routes we want the application to capture and define how to process them. This is your URL Router and it is your best friend!
Install the route-visualizer
module to visualize the router graphically. This is a huuuuge help when building APIs or anything with routes.
install route-visualizer
Let's add our new routes BEFORE the default route. We add them BEFORE because you must declare routes from the most specific to the most generic. Remember, routes fire in declared order.
You can see if that if action is a string, all HTTP verbs will be mapped there, however a struct
can also be provided that maps different verbs to different actions. This gives you exact control over how the requests are routed. We recommend you check out our Routing DSL guide as you can build very expressive and detailed URL patterns.
Route Placeholders
The :userID
part of the route pattern is a placeholder. It matches whatever text is in the URL in that position. The value of the text that is matched will be available to you in the request collection as rc.userID
. You can get even more specific about what kind of text you want to match in your route pattern.
Numeric Pattern Matcher
Append -numeric
to the end of the placeholder to only match numbers.
addRoute( pattern = 'user/:userID-numeric' );
This route will match user/123
but not user/bob
.
Alphabetic Pattern Matcher
Append -alpha
to the end of the placeholder to only match upper and lowercase letters.
addRoute( pattern = 'page/:slug-alpha' );
This route will match page/contactus
but not page/contact-us3
.
Regex Pattern Matcher
For full control, you can specify your own regex pattern to match parts of the route
addRoute( pattern = 'api/:resource-regex(user|person)' );
This route will match api/user
and api/person
, but not /api/contact
Placeholder Quantifiers
You can also add the common regex {}
quantifier to restrict how many digits a placeholder should have or be between:
If a route is not matched it will be skipped and the next route will be inspected. If you want to validate parameters and return custom error messages inside your handler, then don't put the validations on the route.
As you can see, you have many options to craft the URL routes your API will use. Routes can be as long as you need. You can even nest levels for URLs like /api/users/contact/address/27
which would refer to the address resource inside the contact belonging to a user.
Returning Representations (Data)
REST does not dictate the format you use to represent your data. It can be JSON, XML, WDDX, plain text, a binary file or something else of your choosing.
Handler Return Data
The most common way to return data from your handlers is to simply return it. This leverages the auto marshalling capabilities of ColdBox, which will detect the return variables and marshal accordingly:
String
=> HTMLComplex
=> JSON
This approach allows the user to render back any string representation and be able to output any content type they like.
renderData()
The next most common way to return data from your handler's action is to use the Request Context renderData()
method. It takes complex data and turns it into a string representation. Here are some of the most common formats supported by event.renderData()
:
XML
JSON/JSONP
TEXT
WDDX
PDF
Custom
Format Detection
Many APIs allow the user to choose the format they want back from the endpoint. ColdBox will inspect the Accepts
header to determine the right format to use by default or the URI for an extension.
Another way to do this is by appending a file extension
to the end of the URL:
ColdBox has built-in support for detecting an extension in the URL and will save it into the request collection in a variable called format
. What's even better is that renderData()
can find the format variable and automatically render your data in the appropriate way. All you need to do is pass in a list of valid rendering formats and renderData()
will do the rest.
Status Codes
Status codes are a core concept in HTTP and REST APIs use them to send messages back to the client. Here are a few sample REST status codes and messages.
200
- OK - Everything is hunky-dory201
- Created - The resource was created successfully202
- Accepted - A 202 response is typically used for actions that take a long while to process. It indicates that the request has been accepted for processing, but the processing has not been completed400
- Bad Request - The server couldn't figure out what the client was sending it401
- Unauthorized - The client isn't authorized to access this resource404
- Not Found - The resource was not found500
- Server Error - Something bad happened on the server
You can easily set status codes as well as the status message with renderData()
. HTTP status codes and messages are not part of the response body. They live in the HTTP header.
Status codes can also be set manually by using the event.setHTTPHeader()
method in your handler.
Caching
One of the great benefits of building your REST API on the ColdBox platform is tapping into awesome features such as event caching. Event caching allows you to cache the entire response for a resource using the incoming FORM
and URL
variables as the cache key. To enable event caching, set the following flag to true in your ColdBox config: Coldbox.cfc
:
Next, simply add the cache=true
annotation to any action you want to be cached. That's it! You can also get fancy, and specify an optional cacheTimeout
and cacheLastAccesstimeout
(in minutes) to control how long to cache the data.
Data is stored in CacheBox's template
cache. You can configure this cache to store its contents anywhere including a Couchbase cluster!
Auto-Deserialization of JSON Payloads
If you are working with any modern JavaScript framework, this feature is for you. ColdBox on any incoming request will inspect the HTTP Body content and if the payload is JSON, it can deserialize it for you and if it is a structure/JS object, it will append itself to the request collection for you. So if we have the following incoming payload:
The request collection will have 3 keys for name, type and data according to their native CFML type.
To disable this feature go to your Coldbox config: coldbox.jsonPayloadToRC = false
Security
Adding authentication to an API is a common task and while there is no standard for REST, ColdBox supports just about anything you might need.
Requiring SSL
To prevent man-in-the-middle attacks or HTTP sniffing, we recommend your API require SSL. (This assumes you have purchased an SSL Cert and installed it on your server). When you define your routes, you can add withSSL()
and ColdBox will only allow those routes to be accessed securely
If your client is capable of handling cookies (like a web browser), you can use the session or client scopes to store login details. Generally speaking, your REST API should be stateless, meaning nothing is stored on the server after the request completes. In this scenario, authentication information is passed along with every request. It can be passed in HTTP headers or as part of the request body. How you do this is up to you.
Another approach to force SSL for all routes is to create an interceptor that listens to the request and inspects if ssl is enabled.
Basic HTTP Auth
One of the simplest and easiest forms of authentication is Basic HTTP Auth. Note, this is not the most robust or secure method of authentication and most major APIs such as Twitter and FaceBook have all moved away from it. In Basic HTTP Auth, the client sends a header called Authorization
that contains a base 64 encoded concatenation of the username and password.
You can easily get the username and password using event.getHTTPBasicCredentials()
.
Custom
The previous example put the security check in a preHandler()
method which will get automatically run prior to each action in that handler. You can implement a broader solution by tapping into any of the ColdBox interception points such as preProcess
which is announced at the start of every request.
Remember interceptors can include an eventPattern
annotation to limit what ColdBox events they apply to.
In addition to having access to the entire request collection, the event object also has handy methods such as event.getHTTPHeader()
to pull specific headers from the HTTP request.
/interceptors/APISecurity.cfc
Register the interceptor with ColdBox in your ColdBox.cfc
:
As you can see, there are many points to apply security to your API. One not covered here would be to tap into WireBox's AOP and place your security checks into an advice that can be bound to whatever API method you need to be secured.
Restricting HTTP Verbs
In our route configuration we mapped HTTP verbs to handlers and actions, but what if users try to access resources directly with an invalid HTTP verb? You can easily enforce valid verbs (methods) by adding this.allowedMethods
at the top of your handler. In this handler the list()
method can only be accessed via a GET, and the remove()
method can only be accessed via POST and DELETE.
The key is the name of the action and the value is a list of allowed HTTP methods. If the action is not listed in the structure, then it means allow all. If the request action HTTP method is not found in the list then it throws a 405 exception. You can catch this scenario and still return a properly-formatted response to your clients by using the onError()
or the onInvalidHTTPMethod()
convention in your handler or an exception handler which applies to the entire app.
Error Handling
ColdBox REST APIs can use all the same error faculties that an ordinary ColdBox application has. We'll cover three of the most common ways here.
Handler onError()
onError()
If you create a method called onError()
in a handler, ColdBox will automatically call that method for runtime errors that occur while executing any of the actions in that handler. This allows for localized error handling that is customized to that resource.
Handler onInvalidHTTPMethod()
onInvalidHTTPMethod()
If you create a method called onInvalidHTTPMethod()
in a handler, ColdBox will automatically call that method whenever an action is trying to be executed with an invalid HTTP verb. This allows for localized error handling that is customized to that resource.
Global Exception Handler
The global exception handler will get called for any runtime errors that happen anywhere in the typical flow of your application. This is like the onError()
convention but covers the entire application. First, configure the event you want called in the ColdBox.cfc
config file. The event must have the handler plus action that you want called.
Then create that action and put your exception handling code inside. You can choose to do error logging, notifications, or custom output here. You can even run other events.
ColdBox Relax
![](https://coldbox.ortusbooks.com/~gitbook/image?url=https%3A%2F%2Fwww.ortussolutions.com%2F__media%2Frelax-185-logo.png&width=768&dpr=4&quality=100&sign=b3df587b&sv=1)
ColdBox Relax is a set of ReSTful Tools For Lazy Experts. We pride ourselves in helping you (the developer) work smarter and ColdBox Relax is a tool to help you document your projects faster. ColdBox Relax provides you with the necessary tools to automagically model, document and test your ReSTful services. One can think of ColdBox Relax as a way to describe ReSTful web services, test ReSTful web services, monitor ReSTful web services and document ReSTful web services–all while you relax!
Please note: Installing relax via CommandBox installs without the examples, if required you will need to obtain the examples from the Relax Github repo here: https://github.com/ColdBox/coldbox-relax
To install the examples place them into the models directory in a subdirectory called 'resources' (as per the Github repo), then add the following relax
structure to your Coldbox.cfc
file:
You can then visit http://[yourhost]/relax
to view Relax.
You can read more about Relax on the Official Relax Doc page (http://www.ortussolutions.com/products/relax) or at it's repository: https://github.com/coldbox/coldbox-relax
Ref Card - https://github.com/ColdBox/cbox-refcards/raw/master/ColdBox REST APIs/ColdBox-REST-APIs-Refcard.pdf
Last updated