A missing slash can make an engineer look in all the wrong places. In January 2013, a developer had a particularly irritating problem: an iOS application sent a POST request, yet the server seemed to receive an empty GET. Blake Watters suggested looking at the server. Perhaps it was redirecting the request. The developer returned with the answer: a path without its trailing slash was being redirected to the version with one. Watters had pointed to the right end of the wire.
It is a small incident, with a small culprit. It also offers a useful entrance to Watters’s working life. His public projects occupy the space where one system meets another: an iPhone and a web service, a test suite and a server, an application event and a remote callback. These are places where perfectly respectable components can combine to produce a thoroughly unreasonable afternoon.
Today, Watters is Founding Engineer, Principal at Baselayer, the business identity and risk company. His earlier work includes creating RestKit, an open-source framework familiar to developers who built connected applications in Objective-C. To follow that history is to spend some time backstage, where software acquires the dependable connections its audience takes for granted.
A library with a less memorable first name
RestKit began in the summer of 2009 as OTRestFramework, an object mapper for XML data from Ruby on Rails applications. By early 2010 it had acquired a shorter name and a wider remit, becoming a general-purpose HTTP toolkit and object mapping system. Watters is its original author. Jeff Arena, Gregory Combs, and Brian Morton appear in its core-team credits, followed by a substantial list of contributors. GateGuru and Two Toasters are acknowledged for supporting the project.
The change of name marks a concrete change in scope. A tool built around a particular kind of backend became something other developers could use for a broader class of problems. That is a recognizable route into open source: a solution acquires enough independence from its first setting to become useful elsewhere. The software begins to have users whose applications its creator has never seen.
In 2011, Watters was CTO at Two Toasters. His RestKit tutorial explained a practical ambition: let programmers concentrate on their application’s data model while the framework handled more of the request, response, and conversion work. An app needed usable objects, rather than merely a successful exchange of bytes. Getting information across the network was one job; giving it a useful shape was another.
The translation desk inside an app
Object mapping is easiest to understand with an ordinary mismatch. A web service returns a field named one way; the application stores it under another. A date arrives as text; the app needs a date object. Related records arrive together; the application needs to preserve their relationships. RestKit’s mapping documentation lays out how those representations can be connected, including nested relationships and cases that require extra instructions from the programmer.
There is a pleasing modesty to this kind of engineering. It does not provide the subject of the application. It helps the application speak to the world outside it. A reader cares that an article appears; the machinery cares which field becomes the title, which becomes the author, and what to do with the publication date. Small agreements make the visible experience possible.
His tutorial walked readers through installation as well as use, including linking libraries and adding the required Apple frameworks. That is an instructive detail. A tool’s elegant idea still has to survive its first encounter with somebody else’s project. The screenshot belongs to that encounter: an unglamorous arrangement of files and checkboxes that stands between understanding a library and actually running it.
Publishing creates a second job
Watters also taught RestKit in person. A January 2011 notice in Carrboro advertised a four-hour hands-on workshop. In March, he introduced the framework at MobileCampRDU, held at Viget’s Durham office. His subject moved between a published explanation and a room of developers, each bringing different experience of the problem.
Teaching changes the unit of attention. The person building a library can think in terms of features and architecture. The person learning it needs to know what to try next. The two views overlap, but they are not identical. An installation step that seems routine to a maintainer may be the place where a newcomer stops for the day.
That difference appears in his April 2011 answer to a developer asking whether their RestKit application design made sense. Watters discussed how responsibilities could be organized, then reassured the questioner that their approach was sound. The answer addressed a person’s judgment as well as their code.
“You are on the right track and the design is fine.”
Blake Watters, answering a RestKit question, April 2011
A May 2013 chat transcript catches a less tidy stage of learning. A developer had moved RestKit into CocoaPods and encountered an assertion failure in a unit-test target. Watters’s opening response asked what the assertion was. The exchange moves through details of the setup. There is no ceremonial introduction, just the ordinary work of making another person’s problem specific enough to investigate.
Smaller tools, explicit rules
RestKit is only part of Watters’s public workshop. TransitionKit, another Objective-C library, concerns state machines: a way to specify the states a system can occupy and the events that move it between them. Its example uses an inbox message that can be unread, read, or deleted. The library includes checks for invalid transitions, callbacks around changes, and tests.
An inbox is a clever teaching choice because its rules are familiar. Reading a message changes its status. Deleting it changes that status again. Software needs to keep track of which changes make sense from the state it is currently in. TransitionKit gives those rules an explicit home. For a developer, that can be easier to reason about than scattered conditions spread through an application.
RakeUp tackles a different chore. It supplies Ruby tasks for starting, stopping, and checking a local Rack server. The project was developed for RestKit’s HTTP test server. In other words, the work needed to test one tool produced another. A reliable test needs something reliable to talk to, and somebody has to manage that conversation’s other participant.
There is also RKMagicalRecord, a small example showing how RestKit and MagicalRecord can share a Core Data environment. Its description expressly limits the project to reference and education. That boundary is useful information for anyone considering the example. Demonstrating that two pieces can fit together carries a different obligation from promising to maintain the combination for every application.
From mobile objects to cloud events
Watters’s older Stack Overflow biography identifies him as VP of Engineering at GateGuru. His public software record also extends beyond the iPhone. The Python package servo-webhooks credits him as its author and records releases in 2020. Built for Opsani’s Servo system, the connector sends events to external services through HTTP callbacks.
Its description addresses the practical complications that follow: asynchronous delivery, retries, timeouts, and hooks that can run before or after an event. A before-event callback can even cancel the event through its response. These are concrete choices about how independent pieces of software cooperate. The language has changed from Objective-C to Python; the problem still lives at a boundary.
The comparison offers a way to read his career without pretending that every project was part of a plan announced in advance. His work repeatedly makes exchanges easier to specify and operate. A mobile application needs a record it can understand. A cloud system needs another service to hear about an event. Each requires an interface that people can use and inspect.
Another classroom, and four cats
There is a separate educational chapter. Arrow LSAT lists Watters as CTO and co-founder alongside CEO Jonathan Rudner and CPO Josh Garfinkel. His team biography describes experience across enterprise web applications, consumer mobile applications, and server infrastructure. The company offers individual LSAT tutoring and admissions advice. His listed role puts technical experience inside a business built around people learning.
The team page has a lighter touch too: Ulysses, its penguin character, is assigned responsibility for mackerel consumption. That is company humor, rather than evidence of Watters’s own jokes. It does give this chapter a different texture from a software repository. Different audiences require different introductions, even when an engineer works in both settings.
An older author biography provides a more personal glimpse. During his Two Toasters period, it described him as an avid runner living in Carrboro with his girlfriend and four cats. It is a snapshot of that time. Four cats are also a useful reminder that the person answering questions about object mapping had a life beyond the editor window, and quite possibly competing claims on his keyboard.
The next identity question
At Baselayer, the surrounding problem is business identity. The company offers verification, risk analysis, fraud intelligence, and monitoring. Its founders are Jonathan Awad and Timothy Hyde; Watters’s position is founding engineer and principal. That distinction gives each person their proper place in the story.
In September 2026, Baselayer announced a $35 million Series A led by M13 and an Agentic Identity Suite. The new offering addresses software agents acting for people and businesses. The company’s stated questions concern representation, authorization, and whether a counterparty can be trusted. It is a current company development, rather than an individual accomplishment to assign entirely to Watters.
Read alongside his earlier work, the setting is intriguing. RestKit helped an application make sense of data received from elsewhere. Agent identity asks what an institution needs to know about software arriving to act on someone’s behalf. The stakes and purposes differ, but both demand careful treatment of what crosses a system’s boundary.
Watters’s career gives those boundaries a human face. There is the person who wrote a framework, the colleague named in its credits, the teacher explaining an installation, and the developer asking which assertion failed. The missing slash is a fitting place to leave him: looking along the connection, considering its other end, and giving somebody a useful next thing to check.