Chapters
This course is archived!
This tutorial uses a deprecated micro-framework called Silex. The fundamentals of REST are still valid, but the code we use can't be used in a real application.
-
Course Code
Subscribe to download the code!
Subscribe to download the code!
-
This Video
Subscribe to download the video!
Subscribe to download the video!
-
Course Script
Subscribe to download the script!
Subscribe to download the script!
Transitions and Client State
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Transitions and Client State¶
Ok, just one more thing: state transitions. We already know about resource state, and how a client can change the resource state by sending a representation with its new state, or data.
In addition to resource state, we also have application state. When you browse the web, you’re always on just one page of a site. That page is your application’s state. When you click a link, you transition your application state to a different page. Easy.
Whatever state we’re in, or page we’re on, helps us get to the next state or page, by showing us links. A link could be an anchor tag, or an HTML form. If I submit a form it POST’s to a URL with some data, and that URL becomes our new app state. If the server redirects us, that now becomes our new app state.
Application state is kept in our browser, but the server helps guide us by sending us links, in the form of a tags, HTML forms, or even redirect responses. HTML is called a hypermedia format, because it supports having links along with its data.
The same is true for an API, though maybe not the APIs that you’re used to. We won’t talk about it initially, but a big part of building a RESTful API is sending back links along with your data. These tell you the most likely URLs you’ll want your API to follow and are meant to be a guide. When you think about an API client following links, you can start to see how there’s application state, even in an API.
Richardson Maturity Model¶
We just accidentally talked through something called the Richardson Maturity Model. It describes different levels of RESTfulness. If your API is built where each resource has a specific URL, you’ve reached level 1. If you take advantage of HTTP verbs, like GET, POST, PUT and DELETE, congrats: you’re level 2! And if you take advantage of these links I’ve been talking about, that means you’ve reached “hypermedia”, a term we’ll discuss later. But anyways, hypermedia means you’re a Richardson Maturity Model grand master, or something. How’s that for gamification?
We’ll keep this model in mind, but for now, let’s start building!
Comments
"Houston: no signs of life"
Start the conversation!
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"silex/silex": "~1.0", // v1.3.2
"symfony/twig-bridge": "~2.1", // v2.7.3
"symfony/security": "~2.4", // v2.7.3
"doctrine/dbal": "^2.5.4", // v2.5.4
"monolog/monolog": "~1.7.0", // 1.7.0
"symfony/validator": "~2.4", // v2.7.3
"symfony/expression-language": "~2.4" // v2.7.3
},
"require-dev": {
"behat/mink": "~1.5", // v1.5.0
"behat/mink-goutte-driver": "~1.0.9", // v1.0.9
"behat/mink-selenium2-driver": "~1.1.1", // v1.1.1
"behat/behat": "~2.5", // v2.5.5
"behat/mink-extension": "~1.2.0", // v1.2.0
"phpunit/phpunit": "~5.7.0", // 5.7.27
"guzzle/guzzle": "~3.7" // v3.9.3
}
}