Posts tagged "http"
Over the course of this series, we’ve started with a simple idea and taken it to some pretty fascinating places. The idea we started with is that a network layer can be abstracted out to the idea of “I send this request, and eventually I get a response”.
I was planning on having a few more posts on different loaders you can build using this architecture, but for the sake of “finishing” this series up, I’ve decided to forego a post-per-loader and instead highlight the main points of a few of them.
So far we’ve built two different loaders that handle authentication, and it’s conceivable we’d want to build more to support others. Wouldn’t it be nice if we could encapsulate all of the “authentication” logic into a single loader?
The last post covered the basics of an OAuth flow: how we check to see if tokens, how we ask the user to log in, how we refresh the tokens, and so on. In this post we’re going to take that state machine and integrate it into an
While Basic Access authentication works for “basic” cases, it is far more common these days to see some form of OAuth used instead. There are some interesting advantages that OAuth has over Basic authentication, such as:
HTTP requests to web apis frequently need to have some sort of credential to go with them. The simplest kind of authentication is Basic Access authentication, and in this post we’ll be adding this feature to our library.
Most networking libraries have the ability to automatically send a request again if the received response wasn’t quite what the client was looking for. Let’s add that to our library as well.
I once worked on an app that used a
Timerto periodically ping a server with a status update. In one build of the app, we noticed that the status server started experiencing CPU spikes, eventually culminating in it not being able to handle any more requests.
Cancelling an in-progress request is an important feature of any networking library, and it’s something we’ll want to support in this framework as well.
There are a couple remaining changes we need to make to our loading interface, and one of them is to allow resetting.
So far we’ve written enough code to describe a chain of
HTTPLoaderinstances that can process an incoming
HTTPRequestand eventually produce an
In this post, we’ll be creating an
HTTPLoadersubclass that will allow us to dynamically modify requests.
So far, the
HTTPLoadingtypes we’ve created have all been loaders that directly respond to an
HTTPRequest. In order to create new kinds of loaders, we’ll need to revisit the
We’ve seen how a single method can provide the basis for loading a request over the network.
Up until now, we’ve been looking at the structure and implementation of a simple request/response model. Now it’s time to talk about how we send requests and receive responses.
Before moving on to sending our
HTTPRequestvalues, let’s make an improvement to our struct. Last time, we ended up with this basic definition:
In the previous post, we took a look at the structure of HTTP requests and responses. In this post, we’ll transform that information into the types we need to model them in Swift.
For a while now I’ve had a series of blog posts floating around in my head on how to build an HTTP stack in Swift. The idea started last spring with Rob Napier’s blog posts on protocols, and matured last summer and fall while I was working at WeWork on an internal Swift framework.