Working with REST services can be extremely error prone. You could have latency, network failures, or at worse case even total down time. I have been writing a lot of code as of late that requires extreme error handling and graceful failing when dealing with remote REST services and in general web calls – like parsing or loading external web sites for DOM evaluation as an example. The issue is you can’t trust the performance or even trust the service is even available and knowing what methods are failing or causing the bottlenecks could be extremely cumbersome. You could implement network profilers to capture what is going on, or, you could implement a CircuitBreaker design pattern and take control of your calls yourself.
Welcome the Circuit Breaker design pattern. This pattern allows you to monitor a specific function call and “break” gracefully if it has taken too long or even fails. This is usually symptomatic with asynchronous calls that may require calling other code on completion, fail, or timeout. Methods like jQueries ajax where you supply the various error, complete, and done methods work great and even languages like Swift and Java have similar callbacks but it lacks data around the calls. The CircuitBreaker design pattern will make your code easier to follow for race conditions and it can even track statistics around the calls…
If you are a Swift programmer you can check out the Swift CircuitBreaker project on GitHub. It has complete documentation and makes using this design pattern very easy and straightforward.
Now, what sets this package apart in my opinion is it also gives a large set of statistics around the calls. Capturing how long calls take (latency), how many successes, failures, and even average response times. From an SLA perspective this is great! You can then quickly identify what remote calls to “other” services are the primary bottlenecks or problems in your application.