In our previous post, we covered the basics of designing a REST API: defining endpoints, using HTTP verbs and performing common read-write operations on data. In this chapter, we’re going to introduce some advanced use and edge cases you may want to consider in order to give your REST API a sound and long-lasting design.
CauseLabs
Learn More Through My Stories
What you need to know about REST.
If you are a developer and you’ve worked in any modern web application, I’m sure this term rings a bell for you. REST stands for Representational State Transfer. If you’re already familiar with the basics, hop over to our look at Advanced REST API design. If you’re in need of an intro, lets dive in and you’ll see why this architectural style has become a de-facto industry standard for back-end APIs.
Analogous Learning and the Path to Staying Curious
When I was 6 years old, I started taking swim lessons. It was at the swimming complex at the University of Tennessee, where I remember watching the diving team practice from the 10 meter platform in complete, terrified awe. Lucky for me, I started with blowing bubbles in the shallow end. Slowly, we progressed to a swimming stroke: the doggy paddle. Did you hear that right? The doggy paddle. The instructor was teaching us how to swim like a dog.
Wrap Up + Getting to Pilot
When we first started, we were refining a problem, onboarding your team, and setting up tools. Now, we’ll do the reverse.
Week 4: Synthesis and Roadmap
This week may be the most important because it synthesizes everything into a decision-enabling Roadmap. This is the why. And the how. And the what to do next.
Week 3: Prototyping
Starting now, we’ll take all of our work during discovery, immersion, and ideation and boil it down into something real. This week is all about the Workshop.
Week 2: Research + Empathy
Hey gang, welcome back. Hopefully by now you’re really powering with your team and starting to feel the momentum of the process. Last week kicked things off with brainstorming and early research. Now, we’ll focus on confirming the direction, trusting your hunches, experimenting beyond your team, and seeking deeper empathy in your process. So let’s get started!
Week 1: Problem Immersion + Drawing Board
This week we’ll dig into the first of two sessions that we call Drawing Boards. In large part they’re exactly what they sound like: a starting place to gather the team and set the focus, built initially around the Problem Statement draft, and a place to keep referring to as the process progresses.
The 4-Week Guide for Digital Innovation
We’re here to help real people like you more easily understand what it takes to build innovative digital tools by doing a few simple things like putting people first, allowing space for collaboration, staying close to those experiencing the problems, and exploring new ways to generate ideas.
Problem Statements in Digital Innovation: The Importance of Asking the Right Question
It all starts with a problem. We’ve found it’s amazingly helpful to have a single statement that represents the nature of the problem, who’s experiencing it, and why it’s so important to solve. We have a simple template you can use, inspired by the ongoing work we do with our friends at IDEO.org.
Two innovation hacks you can implement immediately
My friend’s forehead was creased, his consternation visible at the intersection of his caved-in eyebrows. “I have to get out of this building to innovate. I can’t do it here. The technology, the dress code, the culture. It can’t get us where we need to go, and even if it could, it wouldn’t do it fast enough.”
How a simple list of emergent themes can save you time and money in digital innovation work
Emergent Themes tries to draw signal from all the beautiful innovation noise, that flurry of empathetic activity that characterizes innovation. Most importantly, these plain-language terms help us have a conversation to answer a key question: “What piece of this problem should we focus on first as we start prototyping?