DEV Community: Mina Slater

Too Beginner to be a Conference Speaker? NEVER!

Mina Slater — Sat, 11 Jan 2020 05:34:19 +0000

When I changed careers into tech, I had a mental retro about what I could've done better in my past career, coming to the conclusion that:

I didn't stay connected enough to the community and...
I found situations that were comfortable and held onto them, avoiding opportunities that challenged me.

So, I made a conscious decision to do the opposite of both of those. I looked for leadership and organizing opportunities in the local tech community and identified things that I was scared of doing, and actively sought out chances to do them.

Public speaking topped that list. 😱

Fast-forward to 2019, after sending out CFPs (calls for paper, or talk proposals) here and there for a year, I got my first acceptance to a major conference, RailsConf. 🎉 It was a conference that I had wanted to go to for a couple years, where some of my Coding Heroes will be presenting, as well. Naturally, I was at the same time excited, honored and of course, terrified!

Spoiler alert: I survived.

Since RailsConf in May I have given that same talk two more times, at THAT Conference in WI and RubyConf, getting less and less terrified each time. Some folks (mostly other Code Newbies) have expressed shock that at less than 2 years in tech, I was "already" speaking at conferences. I always told them that they can too, and should.

Here are the reasons why.

Fresh Perspective

We bring a set of new perspective with us when we come into the tech industry. Our experiences before entering tech might inform a simpler approach to completing the task or we might ask different questions than a Senior Engineer would. While our experience might be limited, we are also not weighed down by the same indoctrination and baggage as someone who'd spent decades in the industry. CodeNewbies are inventive. We don't have the notion of "we've always done it this way"; All these tools are new to us and in our attempt to manipulate computers to do complicated things, we sometimes discover new ways to use these tools that folks might not have thought of.

And what better place to share these discoveries than on a conference stage?!

Motivation to Learn

When I first decided to submit a proposal for a conference talk titled "Bridging the Knowledge Gap: Debugging", I was not good at it. Whenever I had to track down a bug, I froze. I had no idea when to use what tool.

Should I put a binding.pry somewhere? If yes, where?

I always forgot to look for information in error messages or server logs. My pair, if I was pair programming, always had to make suggestions and point out the next steps to me. I constantly wished that my bootcamp had taught me more about debugging.

The purpose of the talk, other than to get into speaking, was to pick a topic that I want to get better at or know more about. This gave me a reason and accountability to do a deep dive that I otherwise might keep putting off. I learned so much during the research phase of preparing the presentation. Now that I've given the talk a few times, I'm feeling more comfortable applying those tools in my daily workflow.

Professional Advancement

Long before my first trip as a speaker to RailsConf, I've wanted to go as an attendee. I streamed the talks from the main room from afar the two years prior to 2019. I watched videos of presentations by really smart folks like Aaron Patterson, Eileen Uchitelle and Justin Searls. I always learned a lot from their talks and regarded them as "coding celebrities".

Attending conferences, it's pretty much a given that you'll meet new people and create professional connections. Attending as a speaker takes this to a whole new level.

A lot of conferences host a reception or dinner for speakers at some point. The ones that I had been a part of took place the night before the first day. At these events, I was able to meet some of the people I looked up to in the Ruby community. I can say, with 100% truthfulness, that I "had dinner with DHH", the creator of Ruby on Rails. We don't have to talk about the fact that it was in a room of about 100 people.

My favorite interaction with one of the "coding celebrities" mentioned above was when Justin Searls tweeted about being nervous before a talk after 10 years of speaking, I replied that it was a relief to hear him say that as a first-time speaker. Then, he came to my talk and complimented me afterwards! 😮

More than that, I have met folks who inspired and encouraged me to write more (Molly Struve), speak more (Colleen Schnettler), take better care of myself (Avdi Grimm), among others. Many of whom I also now consider friends.

Conclusion

All that said, the best reason I have found for me to keep speaking (even though imposter syndrome runs amok) is this:

There's always someone working to be where you are.

Even though I started speaking as a major stretch goal in a new career and to face my fears of public speaking, I keep doing it because I want to inspire other early-career developers to get up and share their learnings and experiences. Experts shouldn't be the only voices we hear on conference stages. Representation matters and we're already experts of our own experiences.

Now I'm going to shamelessly include a video of my first conference talk:

Resources

Articles on writing proposals:
What I learned from reading 429 conference proposals by Noel Rappin
Conference Prompts: Or How to Submit Proposals and Influence People by Noel Rappin
What Your Conference Proposal Is Missing by Sarah Mei

I would also recommend checking out your local Write/Speak/Code meetups. They do a great program called Own Your Expertise that I highly recommend.

Debugging Part 3 - General Tips

Mina Slater — Fri, 27 Dec 2019 16:29:06 +0000

Part Three of the **Bridging the Knowledge Gap* Series on Debugging*

Check out Part One here and Part Two here

Learning syntax is only a small part of being a developer. The transition from coding bootcamp or online tutorials to the Real World can be a struggle. The objective of this series of blog posts is to summarize the knowledge that I gained during my own transition period (and beyond), and pay it forward to those that find themselves in a similar position.

Debugging

A reminder of the debugging topics that we will be covering:

Part Three: General Tips

Bugs and errors are normal parts of software development, because developers are only human. We have already covered some tools that will help us debug our program. In this post, we will have a look at some approaches that have worked for me. They're not "best practices" (what does that mean, anyway?!), just some mindsets I have picked up from my mentors and peers along the way.

Scenario

Recently, my pair Shamyle and I wrote a method to sort some ActiveRecord objects returned from a couple of queries into one list. We had one database query that returned an ActiveRecord Relation, a list of Evaluations, and another query that returned one single Evaluation. The purpose of our method was to sort these results into one list based on certain attributes, so that the frontend will display them in the proper order.

Something like this (shortened for reasons):

def display_evaluations
  list_query = Evaluations.where(...attributes)
  single_query = Evaluations.find_by(...other attributes)
  list_query << single_query
  list_query.sort(date: :desc)
end

With a fully green test suite and the UI revealing no unexpected behaviors, after the team reviewed it, we merged it into the codebase.

A couple hours later, when Sasha was working in the QA environment, she found that the page we worked on was broken. After a little bit of investigating, she concluded that the page couldn't render because one of those queries to the database returned nothing. Our method was adding a nil into the list of objects we pass to our frontend, but when it tried to display something that was undefined, everything fell apart.

Tip #1 - Write Tests

One of the first things I do when I find a bug now is write tests because we want to make sure that any future changes to the code won't result in the same bugs again. Tests to cover the conditions under which our bugs show up will prevent that code regression and let us know when the bug has been fixed.

For the case above, I ended up working with her to find a solution for the bug and the first thing she suggested we do was write tests to cover this particular state of the program. Our test basically said, "hey, if one of the queries came back with no result, exclude it from the list of objects to render by not pushing it to the array we return!"

We didn't know when we started debugging what specific lines of code we needed to change or what that change looked like. But backed up by the tests, we would know right away when it's been fixed. Having comprehensive tests can also help with our next tip.

Tip #2 - Make Small, Incremental Changes

When I first started coding, I had the tendency to make (what I know now to be) wild guesses about the cause of my bugs. I would encounter something that's broken and immediately try to fix it in the code, glossing over the error messages. In my random attempt at a solution, I might touch multiple files and methods. At the end of the flailing, the bug would either still be there or something else altogether was broken, and I would have no idea where to begin backtracking the many changes I just made. 😱

Tech folks like to talk about TDD (Test Driven Development) as a Best Practice. I would also define TDD as Test Driven Debugging. Regardless whether our task is to create a new feature or fix a buggy old feature, having tests gives us a roadmap to our goal.

Sasha and I wrote our tests, and much like with the TDDev approach, each change in code only addressed the specific way the tests were failing or a specific error we saw at that moment. So each time we tried a solution, we would run the tests, hoping that they would fail in new and exciting ways, informing our next step(s).

Tip #3 - Challenge Assumptions

Bugs exist because we think our codes works one way when it really works another way. There are things about our program that we take for granted to be true. How many times have you said something like this:

This method returns an array of objects, so when we call it here, the other method can iterate through it.

...only to find that the first method returns a different data structure sometimes?

They say that the first step to recovery is admitting that you have a problem. In order to debug efficiently, we have to admit that what we think we know about our code isn't always true. We can begin by asking ourselves these questions:

🚨What do I think my code is doing?
🚨What is my code actually doing? (by using some tools from Parts 1 and 2, maybe)
🚨How does this disconnect cause problems in the program?

In the case of our example:
💡I thought both of my queries would return something.
💡...but in actuality, those queries could return nothing from the database.
💡When the frontend tries to iterate through and display components for each item in the list, it doesn't know what to do with an undefined or null.

Conclusion

Sometimes in our jobs as developers, it feels likes we're just putting out fire after fire.

So, good debugging habits are almost as important as writing clean code.

In a perfect world, bootcamps would put more emphasis on teaching the techniques and practice of debugging; it would prevent their graduates from learning bad habits and prepare us better for our first jobs.

I'd like to go back to Aaron Patterson again here to close this talk. I found a tweet the other day, that he had pinned from back in January.

Knowing Tenderlove, he was probably making a joke, but this actually made me feel more at ease about debugging. Because when we frame it in this way, errors and bugs are just edge cases that we haven't considered yet. So we shouldn't be intimidated by them.

And, I hope after these three posts, you are now empowered to debug with confidence!

Debugging Part 2 - Network Monitoring and Server Logs

Mina Slater — Mon, 09 Dec 2019 00:00:00 +0000

Part Two of the "Bridging the Knowledge Gap" Series on Debugging
Check out Part One here

Debugging

A reminder of the debugging topics that we will be covering:

"Look under the hood" - Print & interactive debugging
"Tap the phone line" - Network monitoring & server logs
General tips

Part Two: Tap the phone line

Browser Developer Tools

As web developers, testing features in the browser as we write code is a fairly standard practice in our typical development flow. Usually, when things aren't working properly, we would expect to see some kind of error in the browser or Javascript console. However, oftentimes, we would be faced with an unresponsive UI or a blank screen.

Something that's really useful in these cases is built right into the browser. If we open up the developer tools, we can see all these tabs. The most useful ones, from left to right, are Elements (HTML & styling), Console (Javascript) and Network (server activities).

In the Network tab, lives a log of our network activities. It shows us whether our app's resources are being downloaded or uploaded correctly, and the status of our application's trips to and from the server.

When we first open up the dev tools, we won't see anything in the logs yet. But once the tab is open, we can reload the page or repeat the action that was problematic and watch the logs populate with all the network activities.

Each row in the table at the bottom represents an HTTP request and the column gives you more information about each of the requests. The ones that I look at most often are the name of the resources, the status, which is the HTTP response code, and the resource type.

Some lines will appear in red if there are bad requests, maybe a 500 internal server error or a 403 forbidden.

When we click into one of these lines, we have access to more details like the request and response headers, and the response body. These sections will let us look at the requests more closely. I typically check to make sure the requests are going out to server with all the information that the backend needs to properly process the request.

In the Headers tab under an individual request line, there's a request payload section that will tell us what information went out to the server, and we can see whether it's behaving as expected or identify where it's not.

On the flipside, there's a Response tab that will show us what came back from the server as a result of our request.

In this case, it looks like our request resulted in a 500 internal server error, because it raised an ArgumentError on the backend because we gave some method the wrong number of arguments.

Server Logs

We can also look for similar information from the server-side by peeking into the server logs.

This is the place our backend will log information about each request coming in, how the server resolves the requests and the result. This is where exception and warnings will show up and where the Pry session will open if the program hits a breakpoint.

We have here the Rails server for Puppygotchi, the example app from Part One: Look Under the Hood. This is all the information the server logged during for the same action from when we saw the network logs in the browser.

Like with the network tab, we can see the HTTP request and which route it hits (Box 1), the response status code (Box 2), and the exception that was raised (Box 3), which we saw in the browser returns as part of the response body.

Takeaway

There are a lot of more advanced ways to read both the Network tab and the server logs, and get them to even better clues on how to approach our bugs. When I was first getting started, I had a hard time even remembering to look in these places; let alone knowing what it was telling me. This is only meant to point out something that's easy to overlook:

even though a bug manifests itself on the frontend doesn't necessarily mean it's something wrong with the frontend code.

I wasted a lot of time looking in all the wrong places only to realize that it was actually a backend issue disguising itself as a frontend error.

I also recommend keep an eye on the Network tab and the server logs as a matter of practice, because it is really beneficial to be familiar with how our programs. As we can saw, the logs don't always tell us when something is misbehaving; they mostly just tell us what is happening. The output definitely are not always color-coded, so if we know what the logs look like when it's correct, we will be able to spot when it's not.

Be patient. The more we read these logs and error messages, the easier it would be next time to spot the important things.

Debugging Part 1 - Print & Interactive Debugging

Mina Slater — Sun, 24 Nov 2019 22:06:24 +0000

As a Career Changer, like many others, I went through a coding bootcamp, where they taught me the very basics of building a web app. Since there is a limit to how much you can teach someone over the course of three months, compromises have to be made. Things like refactoring, testing and debugging don't get the same attention.

Because of this, when I started working, I instantly discovered that there is so much I still had to learn; syntax is only a small part of it. I'm sure my experience was not that unique and a lot of bootcamp grads struggle at our first jobs because of it.

From that revelation the "Bridging the Knowledge Gap" series was born.

The objective here is to pay it forward. Even as a Beginner, I realize that there's always someone that's working hard to get to where I am. I can't travel back in time and give Past Me the knowledge and skills that I have now, but hopefully I can help others narrow the gap between Bootcamp and the Real World.

Debugging

The first topic I want to cover is debugging. As developers, we spend a lot of our time navigating code that doesn't work, and when I first started learning to code, I thought errors were telling me that I did something wrong . Since we've all been conditioned to avoid mistakes, they felt like failures. As an attempt to avoid error messages, I just didn't run my code as often.

Since then, I've learned that errors are actually my friends and picked up a few tactics for handling bugs. I’ve organized the things I learned about debugging into three main parts, each the focus for a post of their own:

"Look under the hood" - Print & interactive debugging
"Tap the phone line" - Network monitoring & server logs
General tips

These are not meant to be step by step instructions, but rather starting points where debugging can begin. Depending on the issue at hand, we can use one of the three, mix and match them, or go another route altogether.

This is Part 1: "Look under the hood", covering print & interactive debugging

Print Debugging

In Javascript, print debugging is achieved by using console.log. In Ruby, we use print, puts or p. Most of the time, we use this strategy to get a look at values of variables at runtime, compare these printouts to expectations to figure out where our code needs changing.

All three of these do similar things: output information from our program into the console.

But where print and puts internally call to_s to turn the thing we want to output into human-readable Strings, p calls inspect internally, giving us more useful information.

For instance, let's say we have an ActiveRecord object, a puppy named Dottie.

irb(main):001:0> puppy = Puppy.first

Inside the Rails console here, we can see the difference between using puts to output our Puppy object (top) and using p (bottom).

irb(main):002:0> puts puppy
#<Puppy:0x00007ff2a2449930>

=> nil

irb(main):003:0> p puppy

=> #<Puppy 
    id: 1, 
    name: "Dottie", 
    stomach: -19, 
    bladder: 24, 
    bowel: 24, 
    bored: true, 
    created_at: "2019-04-21 19:37:34", 
    updated_at: "2019-04-28 01:06:28", 
    user_id: 1>

Depending on what problems we are trying to debug at the time, we might choose one over the other.

Print debugging lets us leave breadcrumbs, in the form of these print statements, around our code and visually track the path of our program and look at actual pieces of data. We can watch and make sure that all the data is as expected and if an output we expected didn't show up, it's safe to say that our program never hit that section of code at all.

To summarize:

🚨 puts - Outputs a human-readable string of the object, with a new line.
🚨 print - Outputs a human-readable string of the object, without a new line.
🚨 p - Outputs information about that specific instance of the object.

Aaron Patterson is a maintainer of both Ruby and Rails, and a famously self-proclaimed puts debuggerer (link to his blog post). In that post, he talks about a lot of very advanced uses for these print methods. Most of the things that he covers in the post feel very much over my head, and honestly, p and puts aren't my favorite tools for digging into the inner-workings of my Rails application. I generally prefer interactive debugging, using a Gem called Pry.

Interactive Debugging

Pry allows us to open up a console session at any given point of our program, just by dropping the line binding.pry into the parts of the code we want a closer look at. Now when we run the program again, it would pause there and give us an interactive console in the terminal. It serves largely the same purpose as using the print methods, but Pry, gives us more freedom.

Here is an app I built years ago to teach myself Rails, called Puppygotchi. The puppies get hungry or bored over time so Users can log in to feed or play with them.

I have put a couple of breakpoints in the service object that ages the puppies and reset their hunger and boredom level. We also have a few private methods that are folded at the bottom.

If we run the program by reloading the page in the browser, the load would catch and appear to be unresponsive. But, over in our server, we can see the request from the reload hit the server and stop at our first binding.pry

Most things we can do in the Rails console are available in a Pry session, such as ls.

Using ls, we can get an overview of everything that is available to us within the current context, PuppyAgingService.

We can see from the output of our this command that the PuppyAgingService has a public instance method, process, but it doesn't show me the private methods, because I don't have access to them from within Pry.

My projects generally couple a gem called pry-byebug with Pry, which gives us commands to navigate through the codebase. The ones I most commonly use are next, step and continue.

So, we're still pry'd into the initialize method in PuppyAgingService here. We are stopped on line 4, and we can tell because of the arrow on the left of the line number. That line of code is telling our @puppy instance variable to point to the puppy object we passed in when initializing the PuppyAgingService and right now, it hasn't been executed yet. If we look at our instance variable puppy, it has no value right now; it's nil.

But if we use the next command, the program will run the next line, assign the value of @puppy variable and stop at line 5.

We can then see @puppy has a value now.

Then, let's say we want to know how the method change_time works, we can use the step command to step into this next method call. This will land us inside the declaration of a private method defined on the PuppyAgingService class.

The last navigation command I want to demonstrate is continue, which will tell Pry to continue running the program until it hits the next breakpoint, which remember we have in the instance method, process.

And when we're done with the session and want our program to carry out the rest of the actions, we can use exit to get out of the Pry session.

To summarize:

🚨 next - runs the next line in the program.
🚨 step - steps into the declaration of the next method called.
🚨 continue - runs the program until the next breakpoint.
🚨 exit - gets out of the Pry session.
🎁 Bonus! whereami - tells us where the Pry session is currently.

Use Case

If you've ever built a Rails project, you've seen this error before:

undefined method 'select' for nil:NilClass

This message is telling us that the code wants to invoke a method, select, on something whose value is nil.

In this example, select is a Ruby built-in method on the Array and Enumerable classes, so if the object it's being called on is anything but an instance of either class, the method call results in this error. It's the message we'll see every time we try to use a method on something has the incorrect data type. Since there are many answers for where, how and why the data is unexpectedly nil, opening up the program using puts or Pry is a decent place to start this debugging process. We can use these tools to identify the problem spots and follow the clues from there to the solution.

Being able to peek under the hood of my program was a game-changer! For me, the hardest part of learning to code was overcoming the disconnect between the text in the files and what shows up in the browser. It's especially hard to conceptualize when working with a dynamically typed language like Ruby, where we can assign data of any type to the same variable without any warning about potential problems.

Resources

I am a puts debuggerer by Tenderlove

pry-byebug docs

Imposter Syndrome: Feels, Not Reals

Mina Slater — Thu, 13 Sep 2018 17:38:39 +0000

Originally published on the DevMynd Software Blog.

Image source: pexels.com

Imposter Syndrome (also known as Doubtia Debilitus) is a wide-spread neurological disorder caused by the disconnect between perception and reality of one’s abilities. It commonly affects newborn Software Developers from a non-traditional background, but has been observed amongst individuals of all dev-ages and backgrounds. It is generally triggered by comparing oneself to a false ideal, and conditions can worsen if symptoms are left untreated.

Symptoms

Some common symptoms include, but are not limited to:

Tunnel Vision — Usually imperceptible at an early stage, you might find yourself hyper-focused on minuscule areas of imperfection in largely successful endeavors. Despite overwhelming evidence to the contrary, you see the venture as a failure as a result.

Paranoid Delusions — The intense focus on small mistakes/areas for improvement can increase in severity and cause you to create inaccurate analysis of your self-worth. The perceived “failure” becomes the defining characteristic of yourself and you become convinced that this unknowledgeable true-self will one day be exposed.

Paralysis — The virus attacks the brain and body with such severity that it can sometimes cause productivity to come to a halt. This is a response to your extremely high perceived rate of failure, and they have concluded that “if I don’t start, I can’t fail.”

Treatments

Doctors recommend the following techniques to treat Imposter Syndrome. These are found to be the most effective treatments by the Researcher; your mileage may vary.

Change it up — Identify and remove yourself from environmental triggers, if only briefly, that could exacerbate symptoms. For instance, if you have consistently been working closely with someone much more experienced, it is suggested that you seek out opportunities to work alone or with someone who is more comparable in experience. While pairing with a senior developer is an excellent learning opportunity, it could sometimes lead to unrealistic expectations and self-assessment of yourself. This could occur no matter how supportive from the team. It is important to remember that though it may feel like you don’t know as much, even experienced developers sometimes Google simple things and you still have skills that are valuable and can contribute to the project.

Celebrate wins — The virus takes hold in your brain by exponentially multiplying negative thoughts. Fight it by celebrating any and all achievements, no matter how minuscule they might seem: “I took on a feature independently.”, “I demonstrated something for the Client.”, or “I gave my first lightning talk in front of a group.” Acknowledge these wins without qualifying it, then find a friend to give you a high-five or, if alone, give yourself a mental one. Consistency with treatment is a challenge, especially as the virus fights back. Keep at it. Maybe once or twice a day to start, and work up the frequency. Pretty soon, it will become second nature.

External affirmation — Taking the previous treatment a step further: when you are given a compliment, be sure to allow yourself to accept it. Strike words like “just”, “only”, “well…”, and “lucky” from your vocabulary. No more responding to compliments with: “It was just lightning talk.”, “Well… So-and-so had done it better.” or “I was lucky I got that job offer.”; a simple “Thank you” will do. Take pride in that someone else have noticed your achievement. Downplaying the significance of what you have done will only create fuel for the virus and feed into the negativity that it craves.

Long Term Effects

Whatever methods of treatment work for you, embrace it. But remember: we are all human. When you lapse and the virus is filling you with negative thoughts, don’t fret. Acknowledge what is happening and remember the achievements that got you to where you are. We are all learning to live with various degrees of imposter syndrome, and clinical trials conducted have uncovered that while the condition is serious, it is not chronic or terminal.

The research cited was from personal experience, no official clinical trials were conducted. No medical personnel were involved in the writing of this article.

What is ReST ?

Mina Slater — Wed, 25 Apr 2018 18:18:37 +0000

What is ReST — An Interview Survival Guide

I was recently caught off-guard at a job interview by this question:

What is ReST?

While my bootcamp instructors drilled us with algorithmic problems as found on Codewars, we did not allocate as much attention to the talk-about-coding type interview questions. Thinking back, it was negligent of me to assume that just because I understand something enough to use it, I could talk about it eloquently too.

WRONG!

I think I mumbled something about using HTTP verbs and URLs. I don’t really remember; I may have blacked out.

The paragraphs and images that follow barely skim the surface of understanding ReST, but should be sufficient knowledge to get you through your interview.

This is also what I wish I had given as my answer.

ReST stands for REpresentational State Transfer

So, now that that’s out of the way, we can get down to what it actually means.

Assuming that you, the Reader, are familiar with the Client-Server-Database structure of most web applications, the short answer is that ReST is a set of guidelines that describes how your client communicates with your server.

Image by: DoodlingDev

A “ReSTful” design is complex; way more complex than an Interviewer is looking for in a short interview answer. Here, we will cover the following:

Endpoints named after resources
Actions performed on those endpoints
Stateless communications

SIDEBAR: If you are interested in diving into the nitty-gritty of ReSt, here is Chapter 5 of Roy Fielding’s dissertation.

HOCKEY!

Let’s say I have a very simple CRUD web application for a hockey league, where I keep track of all the teams in the league. Upon surveying the Users, I have condensed the user stories down to the following:

As a User, I want to be able to create a team, so that I can add a new team when they join the league.
As a User, I want to see (read) all the teams, so that I can get an overview of the league.
As a User, I want to be able to update a team’s information, so that I can track wins and losses.
As a User, I want to be able to delete a team, so that I can remove a team when they leave the league.

Knowing that a route consists of two parts: the path / URL and an HTTP action verb, let’s get started.

Resources as Endpoints

In a ReSTful architecture, the path is a noun describing a resource that is being accessed. It is generally named after database models (tables). These paths are the endpoints our client requests will hit.

In the hockey app above, our requests should all hit the path representing the Team resource. So let’s start the routes there and build up:

1. /team

2. /teams

3. /team

4. /team

Actions on Endpoints

If all these User Stories hit the same endpoint, how does the server know which of the actions to perform?

In order to differentiate between each of the CRUD activities, our request from the client will also send an HTTP action verb to the server, along with the path of the endpoint the app wants to hit.

Let’s update our routes for the hockey app:

1. POST /team

2. GET /teams

3. PUT or PATCH /team

4. DELETE /team

Stateless Communication

Another big part of ReSTful design is that the “communications must be stateless in nature” (Roy Fielding). That simply boils down to the fact that all the information needed to understand each request is sent along as part of the request itself.

For our hockey app, we will need to add something to the PUT/PATCH and DELETE routes so that our server knows which team we want to apply the action to.

Like so, where 1 will be the id of a specific team:

1. POST /team

2. GET /teams

3. PUT or PATCH /team/1

4. DELETE /team/1

TL;DR

To sum up the above points into a concise answer to the question, “What is ReST?”:

ReST is a structure for the communication between client and server, where each path is a noun, named after the resource being accessed. The requests contain an HTTP verb to define the action to be performed on the endpoint, as well as everything necessary to understand the request.

There you have it. It is two weeks late for that interview, but here is my answer.