Overview of REST APIs4:55 with James Churchill
Let's do a quick review of what makes an API RESTful.
Representational state transfer, or REST, was introduced and 0:00 defined in 2000 by Roy Fielding in his doctoral dissertation. 0:04 Not every restful service implements every aspect of REST, 0:10 because of this sometimes these services are simply referred to HTTP APIs. 0:14 The web is, by design, stateless. 0:21 After the server responds to a request, 0:24 it forgets about the client that made that request. 0:27 In fact, when making subsequent requests, 0:30 a different server might handle each request. 0:33 REST embraces the statelessness of the web and 0:36 expects that state is being maintained on the client. 0:39 REST APIs are composed of resources. 0:43 Resources are the things that we want to retrieve, create, or 0:46 modify through the API. 0:50 They typically map to an applications models, 0:52 though this isn't a hard requirement. 0:55 Resources are represented by Uniform Resource Identifiers, or URIs. 0:58 These URIs, or 1:05 end points, represent either a collection of records or a single record. 1:06 As we work with the REST API we make HTTP requests against these endpoints. 1:12 Each request is associated with a HTTP verb or method. 1:18 These are the actions that we take against resources. 1:22 There are four main HTTP methods that are used with REST APIs. 1:26 The GET HTTP method fetches a collection of resources or a single resources. 1:31 POST adds a new resource to a collection. 1:37 PUT updates a resource. 1:40 And DELETE deletes a resource. 1:42 Different aspects of an HTTP request can be used to inform 1:45 how that request should be handled. 1:49 For instance, when making a GET request against a collection of resources, 1:52 the query sting can be used to instruct the API how to sort the returned data 1:57 by passing values as key value pairs via the URL. 2:01 And the accept header can be added to the request 2:06 to instruct the server how to format the returned data. 2:10 That's just one example. 2:14 Many other headers are available that can be implemented 2:16 to make your API transactions cleaner and more explicit. 2:19 When creating or updating a resource by doing a POST or 2:25 PUT request, the request message body is used to send data to the API. 2:28 This data can be formatted in a variety of ways including 2:34 form-data, x-www-form-urlencoded, or JSON. 2:39 After processing a request, REST APIs will return an HTTP response to the client. 2:45 Each response contains a status header which is used to tell the client 2:51 the result of the request using standard HTTP status codes. 2:55 HTTP status are organized into four blocks. 3:01 The 200s indicate that the request was received, understood, and accepted. 3:05 In other words, everything is okay. 3:11 The 300s indicate that the request was understood but 3:15 the content is now located elsewhere. 3:18 300 status codes are use for redirections. 3:21 The 400s indicate that an error was generated by the client. 3:25 And the 500s indicate that an error was generated by the the server, or 3:30 that the server is incapable of performing the request. 3:34 Each of these blocks contain more specific, meaningful status codes. 3:38 For example, a 201 status code means that the request was successful and 3:43 a new resource was created. 3:48 A 404 status code means that the requested resource wasn't found. 3:50 Using a more specific status code when it's available 3:55 will help clients to more fully understand the result of a request. 3:58 REST APIs will also include a message body if it's appropriate. 4:03 For example, when fulfilling a GET request, 4:08 the API will include the requested resource or 4:10 resources in the response message body if the request was successful. 4:14 The message body is often JSON formatted data, though that's not a requirement. 4:19 If the request failed, the message body will typically contain an error message 4:25 explaining the nature of the error. 4:29 If any part of this review is confusing or 4:32 new to you, considering pausing this course for 4:35 a bit in order to spend a little bit more time learning about REST APIs. 4:37 See the teacher's notes for links to resources that can help. 4:42 Next up let's do a short quiz on REST APIs, then we'll take a look at 4:46 the client application that will be consuming our service. 4:50 See you in a bit. 4:54
You need to sign up for Treehouse in order to download course files.Sign up