REST (representational state transfer) is an architectural style for HTTP services. It treats a service as a network of resources, such as courses, identified by URIs. Clients use methods such as GET and POST to retrieve or change resource state. REST is not a formal standard, so implementations can vary. section 3.2
A RESTful service follows several design constraints:
- Separate client and server, and keep no client context on the server between requests. section 3.2
- Allow intermediaries such as proxies, and make responses cacheable where appropriate. section 3.2
- Use a uniform way to address and manipulate resources. GET does not change resource state; POST, PUT, and DELETE can. section 3.2
In Actix Web, implement an API as a route combining an HTTP method, a resource path, and a handler. The HTTP server passes a request to the application, which selects a handler by method and path. The handler reads payload or path parameters, accesses application state, and returns an HTTP response. A health-check route is a small starting point before adding resource routes. section 3.3 section 3.1.1
Course API
Group course routes under /courses. POST /courses creates a course from a JSON payload; GET /courses/{tutor_id} lists a tutor’s courses; GET /courses/{tutor_id}/{course_id} retrieves one course. The initial handlers use shared, thread-safe in-memory state rather than a database. Test GET requests in a browser and send POST requests with curl. section 3.2.1 section 3.2.4
pub fn course_routes(cfg: &mut web::ServiceConfig) {
cfg.service(
web::scope("/courses")
.route("/", web::post().to(new_course))
.route("/{tutor_id}", web::get().to(get_courses_for_tutor))
.route("/{tutor_id}/{course_id}", web::get().to(get_course_detail)), #1
);
}
The course-route configuration shows how one resource scope maps POST and parameterized GET paths to separate handlers. section 3.2.6
Automated handler tests can supply JSON payloads or path parameters and check responses. The demonstrated tests are starting points, not exhaustive success-and-failure coverage. A relational database can replace the initial in-memory store as the service evolves. section 3.2.6 section 3.2.1
