DEV Community: Mark Townsend

Working with JWTs in Laravel (Without the Magic)

Mark Townsend — Mon, 30 Mar 2026 18:36:33 +0000

If you've worked with APIs, authentication, or third-party integrations, you've almost certainly run into JWTs (JSON Web Tokens).

JWT (pronounced: JOT) is a compact string used to pass data between systems. It has three base64url-encoded parts separated by dots: header, payload, and signature. The header defines metadata like the algorithm, the payload contains claims such as user id and expiration, and the signature ensures integrity. The header and payload can be decoded into JSON for quick inspection.

Let's create a simple trait you can use on any class in your Laravel application to read the contents of a JWT:

<?php

namespace Quartzy\Illuminate\Support\Traits;

use Illuminate\Support\Str;

trait InspectsJwt
{
    public function inspectJwt(string $jwt): array
    {
        if (!str_contains($jwt, '.')) {
            return [];
        }

        return collect(explode('.', $jwt))
            ->map(function (string $segment) {
                $decoded = base64_decode(
                    Str::of($segment)
                        ->replace('_', '/')
                        ->replace('-', '+')
                        ->__toString()
                );

                return json_decode($decoded, true) ?? [];
            })
            ->filter() // removes empty payload elements from the array
            ->reduce(fn (array $carry, array $item) => array_merge($carry, $item), []);
    }
}

Now you can inspect the contents of JWT with ease! Let's look at an example where a user is making a request to our app and their JWT token is passed as a header in the request. This would be our example JWT:

(You can copy the following JWT and examine it on JWT.io
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI2Nzg5MCIsInV1aWQiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDAiLCJuYW1lIjoiTWFyayBUb3duc2VuZCIsImVtYWlsIjoibWFyay50b3duc2VuZEBleGFtcGxlLmNvbSIsInJvbGUiOiJkZXZlbG9wZXIiLCJpYXQiOjE3MTAwMDAwMDAsImV4cCI6MTcxMDAwMzYwMH0.signatureplaceholder

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Quartzy\Illuminate\Support\Traits\InspectsJwt;
use App\Models\User;
use Illuminate\Support\Facades\Log;

class AuthenticateWithJwtUuid
{
    use InspectsJwt;

    public function handle(Request $request, Closure $next)
    {
        $authorization = $request->header('Authorization', '');

        if (str_starts_with($authorization, 'Bearer ')) {
            $jwt = substr($authorization, 7);
            $payload = $this->inspectJwt($jwt);

            if (!empty($payload['uuid'])) {
                // Pull user by UUID instead of numeric ID
                $user = User::where('uuid', $payload['uuid'])->first();

                if ($user) {
                    $request->attributes->set('user', $user);
                    Log::info("JWT authenticated user {$user->name} with role {$payload['role']}");
                }
            }
        }

        return $next($request);
    }
}

That's all there is to it! Hopefully this helps demystify JWTs and simplifies working with them in your application!

Learn all Eloquent lifecycle hooks in less than 5 minutes

Mark Townsend — Mon, 22 Apr 2024 15:44:49 +0000

Laravel's Eloquent Observers are powerful tools that allow you to attach actions to model events that occur throughout your app. These events include creating, updating, deleting, and more, providing a convenient way to respond to changes in your application's data without having to scatter code all over your app's codebase.

Implementing observers involves creating a dedicated class for each model, usually within the app/Observers directory, and defining methods that correspond to the desired model events. This separation of concerns enhances code readability and makes it easier to manage application logic, especially as it grows in complexity.

Here is a list of all the Laravel model events you can listen for, utilizing Post as our example model:


namespace App\Observers;

use App\Models\Post;

class PostObserver
{
    public function retrieved(Post $post): void
    {
        // Logic to be executed just after a Post is retrieved from the DB
    }

    public function creating(Post $post): void
    {
        // Logic to be executed just before creating a new Post is being created for the first time
    }

    public function created(Post $post): void
    {
        // Logic to be executed after creating a new Post is created for the first time
    }

    public function updating(Post $post): void
    {
        // Logic to be executed just before updating a Post
    }

    public function updated(Post $post): void
    {
        // Logic to be executed after updating a Post
    }

    public function saving(Post $post): void
    {
        // Logic to be executed just before saving a Post (fires for both create and update)
    }

    public function saved(Post $post): void
    {
        // Logic to be executed after saving a Post (fires for both create and update)
    }

    public function deleting(Post $post): void
    {
        // Logic to be executed just before deleting a Post
    }

    public function deleted(Post $post): void
    {
        // Logic to be executed after deleting a Post
    }

    public function forceDeleting(Post $post): void
    {
        // Logic to be executed before force deleting a Post
    }

    public function forceDeleted(Post $post): void
    {
        // Logic to be executed after force deleting a Post
    }

    public function restoring(Post $post): void
    {
        // Logic to be executed just before restoring a soft-deleted Post
    }

    public function restored(Post $post): void
    {
        // Logic to be executed after restoring a soft-deleted Post
    }

    public function replicating(Post $post): void
    {
        // Logic to be executed after replicating a Post
    }
}

Creating a FAQ accordion WITHOUT any Javascript!?

Mark Townsend — Mon, 23 May 2022 02:35:30 +0000

You've got a product or platform and you've anticipated the questions that are commonly asked. Time to build an FAQ (frequently asked questions) page to save you the time of answering the same questions repeatedly.

Did you know you don't even need to touch Javascript to make a beautiful accordion FAQ? Sounds crazy, right?! All we need is HTML and CSS. For this demonstration I'm going to be using Tailwind 3+ (because of its integration with JIT) to show you how easy it is. Let's get started!

If you want the full source code skip to the bottom.

Let's start with the most basic markup:

<section>
  <details>
    <summary>
      Question 1
    </summary>
    <p>Answer 1.</p>
  </details>

  <details>
    <summary>
      Question 2
    </summary>
    <p>Answer 2.</p>
  </details>

  <details>
    <summary>
      Question 3
    </summary>
    <p>Answer 3.</p>
  </details>
</section>

The details tag automatically gives us the ability to show and hide content outside of the summary by default. It's where all the magic happens that allows us to completely skip using any Javascript.

The first thing we want to do is get rid of the browser's basic arrow character so we can style everything ourselves. Tailwind has a handy pseudo element selector called marker: which lets us style this. You may think that marker:hidden would do the trick to get rid of those pesky arrows, but surprisingly, it doesn't! However, because the browser treats them as inline text we can simply make them disappear by setting their font size to 0. Adding the following onto each <summary> tag will do the trick: class="marker:[font-size:0px]"

<section>
  <details>
    <summary class="marker:[font-size:0px]">
      Question 1
    </summary>
    <p>Answer 1.</p>
  </details>

  <details>
    <summary class="marker:[font-size:0px]">
      Question 2
    </summary>
    <p>Answer 2.</p>
  </details>

  <details>
    <summary class="marker:[font-size:0px]">
      Question 3
    </summary>
    <p>Answer 3.</p>
  </details>
</section>

Now that we got rid of those ugly arrows we can add our own. Let's make the summary a flex box and add svgs so we can make it look better.

<details>
<summary class="flex flex-row items-center justify-between marker:[font-size:0px]">
  Question 1
  <svg class="h-6 w-6 rotate-0 transform text-gray-400" xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor" aria-hidden="true">
    <path stroke-linecap="round" stroke-linejoin="round" d="M19 9l-7 7-7-7"></path>
  </svg>
  </summary>
  <p>Answer 1.</p>
</details>

Awesome! We've got our nice arrow now. Looks a lot better. But immediately you'll notice a problem. It doesn't rotate when we open it to show that the content has been expanded.

If you click on the summary tag you'll notice an html attribute of open being added. We can target this with CSS to apply css to the svg and make it transform and rotate accordingly. To do this, we're going to have to apply Tailwind's group class on the details element so we can make the svg react when it changes. We'll add a class of group-open:rotate-180 to the svg itself.

<details class="group">
<summary class="flex flex-row items-center justify-between marker:[font-size:0px]">
  Question 1
  <svg class="h-6 w-6 rotate-0 transform text-gray-400 group-open:rotate-180" xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor" aria-hidden="true">
    <path stroke-linecap="round" stroke-linejoin="round" d="M19 9l-7 7-7-7"></path>
  </svg>
  </summary>
  <p>Answer 1.</p>
</details>

It's really starting to come together now and we still haven't needed Javascript. Let's add a little polish with colors, font size, padding and make the cursor change to a pointer on hover.

<section class="grid grid-cols-1 gap-y-3 divide-y">
  <details open class="group py-1 text-lg">
    <summary class="flex cursor-pointer flex-row items-center justify-between py-1 font-semibold text-gray-800 marker:[font-size:0px]">
      Question 1
      <svg class="h-6 w-6 rotate-0 transform text-gray-400 group-open:rotate-180" xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="2" stroke="currentColor" aria-hidden="true">
        <path stroke-linecap="round" stroke-linejoin="round" d="M19 9l-7 7-7-7"></path>
      </svg>
    </summary>
    <p class="text-gray-500">Answer 1.</p>
  </details>
  ...

That's looking really close to finished. You can just add your personal touches and it's ready to answer all those questions you don't have time to respond to!

One final thing to know about this is if you add an open attribute onto the <details> tag it will automatically be expanded on page load. You can use this with a snippet of Javascript or to simply have the first item already opened for the visitor. If you need to apply any more styling to the <summary> tag when it is expanded, just use the marker: pseudo selector in Tailwind.

You can view the full source code at this Tailwind Playground.

If you liked this article, please give it a like or share it on Twitter!

Revealing hidden elements when hovering a parent with Tailwind CSS

Mark Townsend — Tue, 31 Aug 2021 01:48:02 +0000

This article was written for Tailwind 2.0. As of 3.0 variants are available by default thanks to the new JIT engine. Please refer to the Tailwind 3.0 docs for further inquiry. However, group should still be the solution to this particular CSS issue.

Tailwind CSS makes it almost too easy these days. Add two classes: text-blue-500 hover:text-blue-700 and you have a perfectly styled link.

But what if you want to hide elements until the user hovers the mouse over a parent element? That type of UI requirement is fairly common for dashboard tables when you want to provide quick access to things without overwhelming the user with a lot of visual clutter.

Tailwind is capable of doing that with group hover. For this example, we're going to reach for a lesser used css attribute: visibility. The difference between visibility: hidden; and display: none; is the browser treats elements with their visibility set to hidden as still being present, but simply...invisible. Their space and padding are still respected, though, as if they were still present. Elements with their display set to none are essentially ignored from the markup. None of their spacing or padding impacts the page until they are visible again. We don't want elements jumping around when the user hovers over our element, so we'll be using visibility: hidden instead of display: none; for this example.

Consider the following HTML:

<div class="group">
   <p>Some content that is always visible.</p>
   <p class="invisible group-hover:visible">I am hidden until my parent is hovered!</p>
</div>

You would probably expect this to work - but it won't. That's because Tailwind's group-hover doesn't support display types out of the box. But, with one line of code, we can easily make it work!

You can add this to your tailwind.config.js file:

...
variants: {
 extend: {
   visibility: ["group-hover"],
 },
},
...

Now, it will work!

One thing to note: the visibility attribute cannot have transitions applied to it since it is an "on" or "off" field. If transitions is something you're after, consider using Tailwind's opacity.

Check out this Tailwind playground link to see group hover working with CSS's visibility class.

Creating powerful tabs with Alpine.js in less than 5 minutes

Mark Townsend — Sat, 30 May 2020 02:02:41 +0000

If you haven't heard of a little Javascript framework called, "Alpine.js" until now, you're about to discover something awesome.

Its creator, Caleb Porzio describes it in his own words:

Alpine.js offers you the reactive and declarative nature of big frameworks > like Vue or React at a much lower cost. You get to keep your DOM, and > sprinkle in behavior as you see fit.

Alpine.js is the definitive middle ground between vanilla Javascript and big frameworks. It effectively does away with the headache of having to write a bunch of event listeners and functions to handle your script functionality. It isn't meant to replace big robust frameworks like Vue and React. Instead, it's meant for those smaller use cases when you want to accomplish something smaller without having to fire up an entire framework.

Got it? Cool.

On to the point, then. Let's make a simple, yet robust tab system with Alpine.js!

To start, let's import alpine.js via the specified CDN. At the time of this post, alpine.js is currently at version 2.XX. Put the alpine script at the end of your head tag: <script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js" defer></script>. Next, we'll write out some basic skeleton html. For our example, let's say we're coding a tab section for the product page of an e-commerce web site. We'll keep it simple with just a description and ratings tab.

<div id="tab_wrapper">
  <!-- The tabs navigation -->
  <nav>
    <a href="#">Description</a>
    <a href="#">Reviews</a>
  </nav>

  <!-- The tabs content -->
  <div>
    Lorem ipsum description.
  </div>
  <div>
    Lorem ipsum reviews.
   </div>
</div>

Basic stuff, a wrapper to hold the tab navigation and and content. Now, let's start sprinkling in alpine.js - you're going to love how easy the syntax is.

<div x-data="{ tab: 'description' }" id="tab_wrapper">
  <!-- The tabs navigation -->
  <nav>
    <a :class="{ 'active': tab === 'description' }" @click.prevent="tab = 'description'" href="#">Description</a>
    <a :class="{ 'active': tab === 'reviews' }" @click.prevent="tab = 'reviews'" href="#">Reviews</a>
  </nav>
...

To start, we're strapping an x-data attribute onto the tab wrapper that contains all of our tab navigation and content. We're using a plain ol' Javascript object for its content. Defining a key of tab and giving it a string value of description. This is how we will tell our tab which one we want activate on the initial page load.

Next, we're strapping 2 attributes onto each navigation link. First, we're leveraging alpine's easy class handling and telling it that we want a class of active applied to the element any time the tab is equal to the string value representation of that tab. We want our users able to see which tab they're currently viewing. Next, we're essentially attaching a click event listener that says, "when this anchor tag is clicked, change the value of tab to X." Take note, we're adding .prevent to the click listener. That is the same as using preventDefault() inside the event listener. We do this just so we're not adding a hash to the url bar.

Let's wire up the tab content to make it actually work.

<div x-show="tab === 'description'">
   Lorem ipsum description.
</div>
<div x-show="tab === 'reviews'">
   Lorem ipsum reviews.
</div>

Bam. That's all we needed to add to wire up our content to show when it is triggered. Crazy simple, right?! We didn't even have to write any custom CSS or apply classes. We're just telling the element to show itself when the value of tab matches its corresponding string value.

This will all work perfectly fine, but what if we wanted to make our tabs share-friendly? Naturally, if you were reading the reviews on the product and wanted to send the link to your friend, they would load the page and have the description tab open by default. What if we could make the tabs SEO and share friendly?

It's pretty easy to do using the browser's native anchor tags and it doesn't require changing very much of our code, either. Let's start by making the default tag dynamic based on the anchor tag in the url.

<div x-data="{ tab: window.location.hash ? window.location.hash.substring(1) : 'description' }" id="tab_wrapper">
...

Since alpine.js works wonderfully with vanilla Javascript, we'll simply use Javascript's native window.location.hash to grab the hash out of the url. We'll approach it by using a ternary operator. If you're not familiar with what a ternary operator is, it's just a condensed if/else statement where the first part is the truth test (window.location.hash), the second part, which is followed by a ?, the if-true code, and the last part, followed by : which is the if-false code. tl;dr: if there's a hash, grab the hash and chop off the first character (.substring(1)) because we don't want the full hash (#description). Otherwise, simply default to the description tag.

Next, all we need to do is adjust the click event listener on each navigation link to push the tab hash into the url.

<nav>
   <a :class="{ 'active': tab === 'description' }" @click.prevent="tab = 'description'; window.location.hash = 'description'" href="#">Description</a>
   <a :class="{ 'active': tab === 'reviews' }" @click.prevent="tab = 'reviews'; window.location.hash = 'reviews'" href="#">Reviews</a>
</nav>

That's all there is to it! Now our tabs will change the url bar and respect the anchor tag within the link. Super SEO and share friendly. And that's just scratching the surface of what alpine.js is capable of doing.

Here's the complete code:

<div x-data="{ tab: window.location.hash ? window.location.hash.substring(1) : 'description' }" id="tab_wrapper">
  <!-- The tabs navigation -->
  <nav>
    <a :class="{ 'active': tab === 'description' }" @click.prevent="tab = 'description'; window.location.hash = 'description'" href="#">Description</a>
    <a :class="{ 'active': tab === 'reviews' }" @click.prevent="tab = 'reviews'; window.location.hash = 'reviews'" href="#">Reviews</a>
  </nav>

  <!-- The tabs content -->
  <div x-show="tab === 'description'">
    Lorem ipsum description.
  </div>
  <div x-show="tab === 'reviews'">
    Lorem ipsum reviews.
   </div>

</div>

One of the best things about alpine.js is that you can copy and paste this code several times on the same page and each section will continue functioning independently because the tab data is scoped to the wrapper container. This makes alpine.js extremely powerful and component-based.

Give it a try. I highly recommend you check out the full alpine.js documentation over on Github and consider using it in your next project.

A beginner's introduction to REST

Mark Townsend — Tue, 12 May 2020 20:19:09 +0000

You're breaking into web development, terms are flying and your head is spinning. What's a REST API?!

For some of the younger generation who are reading this, believe it or not, there was a time when web development was a lot more simple. Write some HTML, tell the user, "welcome to my site!" and copy and paste a visitor counter - done 🎉

Now-a-days web sites need to do more than just connect to a database and display information. They need to connect to other web apps to display information, sync information and perform a myriad of automated and supplementary tasks. It's inevitable, so let's just say it: you need to learn how REST APIs work so you can create and consume them.

If you're just being introduced to REST this post is for you.

Web development practices, including REST, are like politics: there are some elements that everyone can agree on and a lot that are contested and debated. Usually these cordial disagreements end up looking like this...

...Yeah, developers are a special kind of gregarious folk - but we mean well.

I'm not going to delve deeply into the theological aspects of REST here, because this is meant to give you a simple look at some of the most basic principles of REST APIs. So, let's get started.

HTTP methods

You can't really begin to understand RESTful architecture until you know your HTTP methods. Let's start with the fab-five. These 5 HTTP methods are the most commonly used in modern day web apps.

GET - Show me information (a list of products, a specific blog post).

POST - Create a new resource (order, register a user).

PUT - A method that will either create a new resource or update an existing resource. It should contain all of a resource's required fields. I.e. if your user resource has 8 required fields, all 8 need to be present.

PATCH - When you need to update a resource, but are not providing all of the resource's required fields. This HTTP method will always be targeting an existing resource where you know the identifier (/users/1482).

DELETE - When you want to delete a resource entirely.

Now, the straggling four. These HTTP methods are not always used in many web APIs, but they do exist and you should know what they do.

OPTIONS - This method is useful for telling developers what HTTP methods a given resource supports. Say I want to know what I can do with the /products endpoint. I send an OPTIONS request and the endpoint will basically tell me, "you can retrieve a list of products ([GET] /products) or a specific product ([GET] /products/32) and update a product ([PATCH] /products/42)". Now I know that resource does not support creating (POST) or deleting (DELETE) products. Responses to this method are not to be cached.

HEAD - This method is very close to a GET request but with one clear difference: there is no request body returned. If you made a GET request to /products and a HEAD request to /products, the GET request would return the normal response headers plus a response body containing products. The HEAD request would only return the response headers with no response body.

Why is HEAD useful? There's a few reasons. First, you might want to check if the resource exists before trying to do anything with it. Second, you might want to check the resource's cache state, which should be returned in the response headers. HEAD is perfect for these use cases.

CONNECT - This method establishes a connection between the client and host, usually for the purposes of creating an SSL tunnel. Usually this method does not contain any data in the request body or response body and favors simply telling whether the connection was successful or not in the response header.

TRACE - This method is used primarily during debugging purposes. It will return the trail of where the HTTP request was sent which could include redirects by the server. This is probably the least used HTTP method of the list.

What does REST stand for?

Quite simply: Representational State Transfer. Got that? It's okay, nobody does when they first hear it.

REST was coined by Roy Fielding in 2000 when he wrote his doctoral dissertation. It was not without good reason that it was picked up and achieved wide range adoption across the web. Previously, developers were stuck with architectural patterns like SOAP (gag), which was not at all simple. The web was the wild west. Roy advocated that developers were not utilizing HTTP as it was originally intended and had a solution: REST.

You see, REST has a few core concepts. We won't take time to review them all, but here's a few important ones:

Statelessness - When you're making API calls (requests) to the server, it doesn't save anything about who you are. Every request you make requires you to provide your authentication information. Usually that comes in the form of tokens.

Proper request methods - In some obvious circumstances the HTTP method you choose to make an API call is not up for debate. If you want to be shown information you use GET. If you want to create information you use POST. You would never perform an action that updates or creates a resource using a GET request.

I once visited a web site while logged in and clicked a link in my dashboard only to be surprised that my account was upgraded to a trial of their premium plan. WHAT? The concept is easy to understand. I clicked a link expecting to see some information and instead they modified my account. The same is true in REST. The GET HTTP method means, "show me information" nothing else.

GET, HEAD, OPTIONS and TRACE are never to be used in directly changing the resource on the server.

Separation of concerns - The client (you, or your web app) has its duties and the server has its own duties. Don't try to force one side to do more than it was intended. Sometimes this means making more separate API calls.

For example, I may want to retrieve data from a server so I have to make several API calls to the server to traverse the various pages, then perform several more separate update API calls to change the data. Your first instinct might be to say, "why not just lump all of that into one endpoint and make one API call?" It seems easier at first, but you'll quickly realize it creates more problems down the road. Not only that, but you've just forced way more work onto the server and absolved the client of its responsibilities to interpret and handle the data.

Caching - It's entirely reasonable to expect the client (your site or person) to cache the data it receives from an API. It's also equally reasonable for the server to cache its response in the interest of speed. Usually the freshness of data is communicated from the server through response headers so your application can know if the response is cached and when it expires. There are also ways for the client to request the server not to return a cached response and fetch fresh data, but the means varies per API application.

A few things I wish somebody told me when I was starting

When working with RESTful APIs, request methods are not a concrete one-to-one connection with your code. REST is a way of thinking which shapes the way you structure and write your code. Your programming language may or may not go out of its way to make that clear to beginners.

My first introduction to REST APIs came by way of PHP. I read through the various HTTP methods and got confused, "why is there no super global corresponding to $_PUT, $_PATCH and $_DELETE?!" The answer is rather obvious now, looking back. GET, POST, PUT, PATCH and DELETE are HTTP methods. It's up to you to find out how your language will allow you to read and send using these HTTP methods. The good news is that many language frameworks handle this for you and make it easy.
You need to start viewing your data as resources. A resource can be anything. Here are some examples of resources: users, orders, products, posts, order statuses, tracking numbers, etc. You get the idea, right?

Now that you're seeing data as a resource, you should be thinking about what operations can be applied to a resource. Say my resource is books:

Get a list of books: [GET] /books/
Get a specific book: [GET] /books/13
Create a book: [POST] /books/
Update some of the books attributes: [PATCH] /books/13
Update every attribute of the book: [PUT] /books/13
Delete the book: [DELETE] /books/13

Notice how the url structure didn't really change much between the operations? The difference was the HTTP method! My API was reading the method and deciding what to do with the resource based on the method and the data supplied (if any). That's a RESTful approach!
Separate resources are the goal. For example, let's say you were designing an API that had countries and their states/provinces. When a request was made for the United States should I send back all 50 states that belong to it? You could, but I would recommend separating them. Make one API call to get the country ([GET] /countries/US), take the country's id and make a separate API call to get the states ([GET] /states?country_id=1).

You're going to find that as your API grows the separation of resources will make it easier to maintain. Does this means you never want to group resources and their children in API calls? No, not necessarily. But don't let your default answer be, "yes" without thinking about it. By making your resources separate you are introducing simplicity into your API and thats a good thing. Each resource endpoint now only needs to worry about itself instead of its children resources.
When creating your REST API make a determination to follow best practices and stick with it consistently. Here are a few examples:
1. Use JSON for your request body. It is simpler and smaller compared to XML.
2. Use nouns instead of verbs for your uris. Your HTTP methods should be specifying what the operation does, not the url.
  
  Correct: [POST] /books
  Incorrect: [POST] /add-books
3. Use plural names for your resource uris. E.g. /products or /products/my-product-slug. Many well-established APIs follow the plural rule because the base endpoint indicates you want a list of that resource.
4. Use resource nesting to denote ownership - but don't go crazy with deep nesting. Keep it at 2, maybe 3 at the most. E.g. /users/1482/orders - will give me all of user 1482's orders.
5. Standardize your error messages. Nobody wants to work with an API that gives vague errors or sometimes shows errors in the response headers while other times showing errors in the response body.

Now you know the basics and some best practices

REST really isn't that hard to grasp. I think a lot of people just struggle separating the principles from the implementation. I hope you found this article useful in helping you begin to grasp the basic concepts of REST - I know I wish someone had told me these things when I was getting started.

Did you learn anything valuable? Did I miss anything? Let me know down in the comments. Thanks for reading!

Learning Javascript, barcode scanning and wiggling into private grocery store APIs

Mark Townsend — Sat, 06 Apr 2019 03:38:46 +0000

I've been a backend web developer for several years now. Swimming in the waters of databases, object oriented programming, and beautiful frameworks like Laravel to create some fairly robust web software for the company I work for, DieselCore. But here I was, realizing that learning a new programming language was well overdue. Sure, I had worked with Javascript plugins and packages before, I considered myself to be capable enough to figure the implementation part out even if I didn't really understand the language itself.

I bit the bullet and signed up for Wes Bos' free 30 day javascript course, Javascript 30. From the day I write this post to when I signed up has been exactly 14 days, and I'm still only halfway through. That has roughly been the extent of my javascript training, in truth, with only a few other small introductions to the language in passing.

That's why I feel proud to have created what I did in such a short time frame. A working web application that scans barcodes, talks to the grocery chain's non-public API, adds products to a list, calculates the total and factors in sales tax.

First-world problems

Let me back up a few steps to a couple of days ago. My wife, Kaitlynn, and I are having dinner while our kids play and she drops a real first-world problem on me: "I hate going to HEB (our local grocery store) because I can never tell what our total will be until I'm at the checkout. By then I may decide something in my basket isn't worth it." I grin, "oh, that's terrible." She laughs and continues, "but if I use the app to order, I feel cheated because we end up focusing on the price and eating the same food over and over. I just miss out on the experience to see new foods that spark fresh meal ideas if I'm not there."

I'll admit, I have a personal love for web APIs, having built several, myself. I begin to think of solutions. "I'm sure there's an app for what you want", I say. I look it up, and there is, but it's limited to locations that are nowhere near ours. Even if it's a first-world problem, I like to problem-solve, and my wife is a fantastic homemaker. If I can make her work even a little bit easier with what I do, I'm hooked.

I check out the HEB app and sure enough: they have barcode scanning. I look up a barcode and try it run it through HEB's web site search - no dice, UPC codes don't return results. But I know there is an endpoint out there serving up product results for UPC codes. But how do I find out where it is?

A clever solution

I remember something my father-in-law always talked about: WiFi honeypots. With the right software you can view network traffic. So, I hatched a plan. I would monitor my home network traffic while using the app and try to catch the outgoing API call.

After awhile I finally settled on the simplest solution: an iOS app called Thor. I started the network sniffer, opened the app and scanned. I crossed my fingers and began scrolling through the network logs hoping I would strike gold.

Bingo! I had an endpoint, and more importantly, I had an api key. This was starting to look like a real possibility now.

I made a few test calls and it worked perfectly. I got to work building the interface. I opted to use the fantastic CSS framework, Tailwind, for my UI. I hooked up all the Javascript components using what I had learned in the prior 14 days and things started looking good.

I did encounter some issues while attempting to utilize Javascript's fetch function, namely CORs errors. So, for the remote API calls I whipped up a quick PHP script to send cURL calls on behalf of my javascript application. That was the extent of PHP's involvement in this project!

Smile for the camera

Now all I had to do was find a way to use a device's camera to convert a barcode and pass it to the API. I had been avoiding this part of the project as much as possible because I knew the limitations of my knowledge well enough to know barcode scanning was more advanced than I could handle right now.

Luckily, there are some really solid JS frameworks out there that handle this very thing. After some digging I found Quagga JS. I had a little bit of trouble getting the configuration right, mainly because the examples they provided didn't 100% match the source code they used, but eventually I got it working.

Here's a fun fact for anyone who has never worked with a device's camera permissions with Javascript: You need an SSL certificate. The browser won't even request access if your script is running on an unprotected protocol. For me, fixing this problem was a cinch because I use Valet to run my local development server. valet secure <folder> and done. I was running https protocol. It was just that easy.

In less than 2 full days I had a working beta version of the web app which promised to cure my wife's shopping woes. See for yourself. Click the image below to watch it in action.

Thanks for taking the time to share in my story. If you're a developer, I hope this inspires you to go out and make something great.

Technologies used

Thor - iOS network sniffer app
Tailwind CSS - css framework for ui development
Font Awesome - icons
Quagga JS - camera access and barcode scanning
Valet - local web server w/ ssl support
HEB - for their kind understanding that I borrowed their api 😅

By the way...

HEB, if you're reading this, I'm open for contract web development work, I'm great with APIs 😉

I love to share

I have several free open source packages available for download on my Github profile. Check them out and see if any of them can save you time in your next project!