Summary

In this chapter, we covered the basics of HTTP, reviewed common practices for creating services for the web, and reviewed the REST style for implementing services over HTTP. Essentially, we learned that HTTP is a standardized protocol that all web servers and clients use in order to ensure they can connect and share data with each other. This protocol has existed for over thirty years and has continued to work despite undergoing several changes. This is also a goal we’ll try to live up to when we create our APIs.

We also covered the idea of the web. Although not an actual protocol like HTTP, the practices of the web—such as the use of HTML for data and actions, JavaScript for extending functionality, and CSS for improving the user experience—have been responsible for the success of the web today. While our APIs won’t need to deal with CSS styling for user experience, and we won’t be using JavaScript to extend them, we’ll follow the common practice of the web by adopting the pattern of sharing messages instead of objects. And we’ll make sure our messages not only include just simple data, but also include rich metadata in the form of HTTP headers and action elements, such as links and forms.

In addition, we briefly reviewed Roy T. Fielding’s definition of REST (REpresentational State Transfer) because it often comes up when creating APIs for the web. Even though REST is just a style and not a protocol or practice, the style has been an important influence in the way programmers—for both service providers and consumers—design and implement their APIs. We’ll use many of Fielding’s REST principles in our API.

Finally, we learned how to use the Git command-line tool to set up our own project repo to track all the files and folders that we’ll add, edit, and delete throughout the lifetime of our API project. We also added a remote repo to the GitHub website and used Git to link and sync our local repo to the remote one.