HTTP Requests with Re-frame
This document explains how to make HTTP requests in the application using Re-frame events and effects.
Overview
The application provides several ways to make HTTP requests:
:http/api
- For making requests to the application's API endpoints:http/auth-api
- For making authenticated requests that automatically include the user's access token:http/request
- For making requests to any URL, not just the application's API
These are implemented as Re-frame effects that can be used in your event handlers.
Basic API Requests
The :http/api
effect is the primary way to make requests to your application's API endpoints.
API Endpoint Specification
API endpoints can be specified in two ways:
Keywords: When using a keyword like
:account/log-in
, it will be automatically converted to/api/account/log-in
Strings: You can also use full paths like
"/api/account/verify"
Authenticated Requests
The :http/auth-api
event is used for making authenticated requests. It automatically includes the user's access token in the Authorization header.
Behind the scenes, this is converted to an :http/api
call with the token included:
Token Refresh Mechanism
A key feature of the HTTP request system is automatic token refresh when authentication fails:
When a request returns a
401 Unauthorized
errorThe system automatically attempts to refresh the token
If token refresh succeeds, the original request is retried with the new token
If token refresh fails, the user is redirected to the login page
This mechanism is transparent to your application code - you don't need to handle token refresh explicitly.
Request Configuration Options
When making requests, you can specify the following options:
:url
Keyword/String
The API endpoint to request
:method
Keyword
The HTTP method to use (:get
, :post
, :put
, :delete
, :head
)
:body
Map/String
The request payload
:headers
Map
Additional HTTP headers
:query-params
Map
URL query parameters
:token
String
Authorization token (added automatically for :http/auth-api
)
:success-path
Vector
Path within response to extract data from
:content-type
Keyword
Request content type (defaults to :transit-json
)
:accept
Keyword
Response content type to accept (defaults to :transit-json
)
Handling Responses
There are several ways to handle responses from HTTP requests:
On Success
Multiple Success Handlers
You can trigger multiple events on success:
On Failure
Multiple Failure Handlers
Common Request Patterns
Login
Authenticated Data Fetch
Form Submission with Loading State
Content Types
The API supports several content types:
:transit-json
(default) - Transit format encoded as JSON:json
- Standard JSON:form-encoded
- URL-encoded form data:text
- Plain text:html
- HTML:edn
- EDN (Clojure data format)
To specify a content type:
CSRF Protection
For non-GET requests, a CSRF token is automatically included in the headers. The token is retrieved from a hidden form field with the ID __anti-forgery-token
.
Error Handling
By default, responses with status codes >= 400 are treated as errors. The error handler will receive either the error object or the response body.
Implementation Details
The HTTP request system is implemented in:
src/cljs/saas/db/events.cljs
: Re-frame event and effect handlerssrc/cljs/saas/query.cljs
: Actual HTTP request implementationsrc/cljs/saas/auth.cljs
: Authentication and token management
Last updated