In this video, Keith Casey discusses implementing an API for our fictional messaging system Chatter and how to navigate the different branches/stages of our project.
- [Instructor] Now let's talk a little bit about the project itself. We're going to build a simple Twitter clone. Well, not quite. We're going to take a simple Twitter-like website, and add an API to it. We'll start with simple interface to retrieve data, and progressively add more functionality, and then work through simplifying our system. Yes, we could start with a completely brand-new API, and do whatever we want the right way from the beginning, but honestly, that's not how most of our projects occur. Even with relatively recent framework based projects, building an API may be an afterthought, or bolted on long after the fact.
Our starting requirements are relatively straightforward. We need to provide an API that allows a user to, first, authenticate securely. We don't necessarily know what this means yet, but that's fine. More than anything, we want to make sure that our users' credentials are protected. Next, we want them to be able to retrieve messages for their own account. Next, we want them to be able to retrieve messages for others' accounts. We also need them to be able to send out a message for others to see. Next, we want to give them the ability to delete one of their own messages, but no one else's.
Finally, we want to allow them to attach an image to their message for sending. Remember, these are all from the perspective of the end-user, or the front end client applications, not from a system administrator, or operational perspective, but we do need to consider those too. On that side, the API will need to log all incoming requests. Later, we might refine this to say all successful requests, or all failed requests, but this is enough for now. Next, we want to authenticate using a simple API key mechanism.
There are tons of options for API authentication. API keys aren't necessarily the best, but they are quite common. We may revise this one by the time we get there too. Next, we want to return the most correct response codes. In many cases, there are multiple response codes that could be used. We're going to try to use the most correct ones, with the understanding that we don't always have to be perfect, but we do have to be consistent. Next, we want to return JSON payloads that are useful to the end clients.
Finally, and most importantly, we need to make sure that the app is manageable as we add functionality and complexity to it. This one is the hardest, and the most important to do. Now, I generally like binary requirements, done or not done, are even measurable, so we can say this is better today than it was yesterday. This last requirement bugs me a little, but it's okay for now. We can always go back and revise as we learn more. These requirements in general, don't worry about the deeper details of those requirements yet.
We'll dig into each as we need to, and learn more about the underlying options and tools available. Without further delay, let's dive into some code.
This course begins with a simple application specification and builds it one step at a time. Each chapter includes a key concept, with examples from other public APIs, and then shows how to build it yourself with Silex. Learn about URL routing, validating input, and generating response codes and hypermedia payloads. Like any project, the first implementation may be a little messy, but don't worry. The last chapter covers refactoring and what it takes to scale and support the API going forward.
- Understanding the project goals
- Adding authentication with Silex
- Using cross-framework and authentication middleware
- Creating a read-write API in Silex
- Uploading files via an API
- Adding file security
- Creating payloads and response codes in Silex
- Scaling your API