REST, HATEOAS & Django - It's OK to not use JSON... or Javascript

Good morning, welcome to DjangoCon. My name is Carson Gross, and I'm going to be giving a talk today on REST, Hadios, and Django. Before I get going, I'd like to say thank you to the organizers of DjangoCon for letting me give this talk. It's a little bit outside the normal content that you might expect. at a at a conference like this, but I think uh you'll see by the end of this talk that it's it's highly relevant to Django developers So in this topic, or in this talk, excuse me, we're going to revisit an old concept that has unfortunately fallen on hard times. And that's the concept of REST, which rest standing for representational state transfer. You may have heard this term, and we'll get into the details of exactly what it means

here in a little bit. But before we get going on that explanation, I I want to point out that we have some actual evidence of the hard times into which rest has fallen here at DjangoCon. There's another talk That's entitled Graphene Django or How I Learned to Stop Resting and Love the Graph. And you may think that I'm going, I might criticize this other talk. in some ways. But in fact, I'm not. I'm quite enthusiastic about that talk. And I think it's evidence for my claim in this talk. which is that the the the broad claim being that rest really applies mainly in a hypermedia or hypertext situation um rather than in a json context And so that's what I'm hoping to convince you of

by the time we get to the end of this talk. You'll uh agree with me that rest and chaos, which is another acronym that we'll explain in more detail uh a bit later is useful but just not in the con not it in the usual context it's discussed in today which is JSON APIs. Let's leave the GraphQL and all that stuff, all that good stuff to our friends in the JSON API world, but we're Django developers or web developers. And let's not give up on REST just because they don't like it. So let's talk a little bit about how web development grew up to give you some some background on where the term rest and the terms rest in Hadios. come from. Web development really started back in the 90s based on this notion of hypermedia.

And the hypermedia that we're most familiar with today is hypertext, usually written in HTML And this was a radically new way of building and distributing software. You can compare and contrast it with the old model of distributing binaries to people, and they have to click and run an installer, whatever it was. Uh the the new hypermedia model was very radical as a software model. And so um people thought a lot about that. And one person in particular who thought a lot about it, who not only built a lot of the original infrastructure, but also sort of put ideas into did the the the intellectual work around the early web was a man named Roy Fielding. He recognized that the web was a fundamentally new computing paradigm, and he wrote his PhD dissertation on it, on the work that he had done at the Apache Project.

And uh it's from that uh it's from that PhD dissertation that uh we get the terms rest, restful, and hateos. Hadios as an acronym is not called out directly in the pa in that uh in that dissertation, but the the concepts were there. So it got formalized a little later. It's important to understand though when uh Roy Fielding wrote this dissertation, there were no JSON APIs. This was a description of the web, of the web architecture that he had been help uh helping to build. And so it it didn't apply uh natively to the JSON world. That uh sort of came later. And so that's an important thing to keep in the back of your head as we're discussing exactly what these acronyms really mean.

So this new network architecture that Fielding was describing, REST, has uh has the following characteristics. He calls them constraints. Um it was client-server architecture, obviously. It was stateless. That was relatively interesting. That was interesting, but not totally unique. It was cacheable. It was layered. and it had a uniform interface. These first four items are interesting and I encourage you to go do some reading on them, but we're not going to focus on them in this talk so much. Instead we're going to focus on the uniform interface. And the reason we're going to focus on it is because it's the most radical constraint of the bunch, in my opinion. This is what really differentiates restful

systems from non-restful systems. So let's uh let's uh ask the question, what is this uniform interface? And this will help us to understand what REST is. Again, my assertion is that this is the crux characteristic of RESTful systems. So the uniform interface consists of four additional constraints on the system architecture. Resource identification has to be found in the requests. Resource manipulation is done through representations. The messages are self-descriptive. And then finally we get to everyone's favorite. Hypermedia is the engine of application state, sometimes pronounced Hadios. And so what do each of these mean? This these four constraints form the uniform interface constraint in REST.

So what do each of these mean in brass tax terms? Well Consider this snippet of HTML and recall again that REST was defining defined in terms of HTML, not JSON. So put that JSON knowledge that you have away, the the um the hierarchy of the Richardson hierarchy of uh mature uh rest maturity and all that stuff. Put it away. Let's just talk about HTML Consider this snippet of HTML. This would obviously be in a larger document, but just consider this by itself. We're emitting some uh some of the tags. retrieved from https example. com slash context slash forty two. So in a normal web application, this HTML would be retrieved by issuing a GET request

I hope you know what a GET request is, to a given URL, like so. And thus the resource identification is embedded in that request. So this is a resource, contacts42 is a resource, and the the uh URL is embedded in the request. So we have this situation where resource identification is in this request that's been issued to retrieve this HTML. So that's satisfying that first constraint of the uniform interface. Secondly, manipulating through resources. Well, note that an end user who retrieves the, who receives this HTML is able to manipulate this, able to manipulate this entity uh through this representation.

They've got options in the form of links here to perform updates. And may you know depending on what they click, they might get a form, they might get some other piece of HTML that gives them further options to update this uh resource. And so the browser here doesn't know What a contact is. Rather, it's just getting a representation of that contact, and with this representation allows the user to actually mutate and update to manipulate this resource uh very interesting. Very a very new way of approaching presenting something like this to a user uh in a software system Self -descriptive messages. Well, as such, these messages you can see are self-descriptive. They contain all the information necessary to interpret themselves

and present a final interface to a user to interact with. So this is all that's necessary for a browser, which again has no notion of what a contact is, to present a useful user interface for a human interact with. To make modifications and updates to this particular resource. And there is a little bit of a symmetry here, I noticed, between this idea and object-oriented programming. In the uh in a RESTful system, you're presented with both the data and the operations on that data in one package. So it's sort of like a class in that sense, like when you get an instance of a class in an object oriented system, you're getting both

the data associated with that instance as well as the methods that are available on that instance. So I thought that was an interesting parallel. And finally we come to the last and probably the most misunderstood constraint, which is Hadios or hypermedia. I like to say hypertext just because it's more familiar, as the engine of application state. So what the heck does that mean? Well, what that means is that the hypermedia or the hypertext or the HTML, depending on how uh uh concrete you want to get. uh contains the the state of the application. So given an entry point into my contacts database, say it slash contacts I don't need to know anything else about the state of any of the contacts that are in that system.

Rather, when I click on a link to view contact 42 , Um this the the state of that uh of of this contact is given to me in hypermedia. So there's no special side state associated with this contact. Everything that I can do with this contact is presented here in the HTML. So the HTML is encoding exactly what I'm able to do in this app. There's no uh there's uh there are no flags or anything like that going on. There's no no side state associated with it. There's no model living on the side in my web application. Rather, I've got my DOM, which is a representation of the parsed HTML which has come down from this remote system. And that DOM

is what is providing me with all of the information about the state of the remote system. So everything is encoded in hypertext, and hypertext is therefore the engine of application state. If for some reason um this uh contact became uh was put into a state where it couldn't be archived, this link might not appear in that situation. And that would be showing me in that case that okay, there's some other that there are operations that are no longer available, or maybe there are operations that have become available. And that would all be encoded in the representation of this contact rather than set as a flag on a local piece of data that I had in a data store, say a contact data store sitting in a JSON

store on the side, just to pick something at random. um that told me whether what uh what operations I could uh make visible to my end user So one interesting thing about this to note is this means that API churn, which you'll read quite a lot of complaints about online, doesn't really matter nearly as much. We can actually change the API around contacts. pretty dramatically here, right? We can add new operations, we can even remove operations and uh to uh the a first order in any event users will just see the new operations that are available or that are no longer available on a contact and they can choose to use them or not use them. And so your API doesn't have to be as stable as it does if, for example, someone is writing a JSON client against an API

If you change that, then suddenly that J that code that had been written against that JSON ABI may no longer be valid. And that's one of the chief sources of flexibility in a truly restful system is this ability to have a single entry point and then allowing the hypertext, the hypermedia, to be the engine of application state for you. So that's a really nice aspect of this of RESTful systems that I think has been lost as REST has been dragged into the JSON community. and out of its native uh HTML or hypermedia uh environment. So If you consider the endpoint uh https

example. com slash contacts slash forty-two slash email, the client again is the browser and it doesn't expect that that URL is there. It just renders a link. It just renders a link. It doesn't care. It doesn't care if the link if uh if uh this uh in an abstract sense if this endpoint exists or not. All it knows is hey you told me it did so I'm going to render it to the end user and that's it. So that is what REST and Hadios is, is this extremely flexible mechanism for presenting server state to an end user. And again, it was a description of this original web model. It was not intended

to be part of the discussion in the JSON world, in the JSON API world Um or at least that wasn't its native, that wasn't the native environment that it came out of. And uh one thing to note is that web 1. 0 applications, so web applications built what today might be termed the old way. naturally implement a RESTful architecture, not always the best way. There are some short shortcomings when it comes to HTML that we'll address here in a little bit that we'll talk about. But nonetheless Um if you've ever built a bog standard web 1. 0 Django application, I'd like to congratulate you because you have created a more complete RESTful API than probably about 99. 9 % of all JSON API developers and JSON API developers

are the people who typically worry about RESTfulness these days. So somewhat ironic. If you're just building old school web apps, you're doing a better job of REST than probably some very highly paid API developers. Who are wondering why they're using Rust at all? So, um, for historical reasons, and this is a long story that I won't get into uh too much, but uh this original understanding of rest w uh has been almost completely lost in the in the industry. Um the and the the reason for that is that The industry, in an understandable effort to improve usability of web applications, began using JavaScript and Ajax to build more dynamic websites. Totally understandable. There were definite usability issues with the original web.

And I'm not going to claim that there weren't. I will claim that it was a better implementation of the restful networking architecture, but I won't claim that it was the best user experience. And because of this, this has led to the rise of the mighty JC JSON API, which is what so many people use today to build their web applications. And these are APIs that use JSON to communicate with the backend. And JSON I hope everyone is familiar with looks something like this. And this is the JSON that might correspond. to that contact that we were just looking at. The uh the contact um HTML that we were just looking at. So

You can see, uh look, it's nice, it's small, feels a lot cleaner in some ways, right? This is great. Everyone loves it. Everyone loves JSON. Certainly less data. Maybe it's faster. I don't know. I think people over uh emphasize uh the size of these of of payloads um depending on what the back end's doing, but whatever, it is it should be a little bit faster anyways. But note that it doesn't encode any actions that are available on this data. So if you were in JavaScript and receiving this piece of data, you would have to know, okay, well I've got this contact. Now I need to know what to do, where to call to do things to it. If I want to email this contact or whatever, you need to know what those endpoints are. It's not encoded in this JSON, is it?

So this is definitely not this is definitely not Hade OS. We're not encoding actions in this JSON payload. And uh a quote from Roy is uh I'm getting frustrated by the number of people calling any HTTP-based interface a REST API. Today's example is the social site REST API. I don't think that exists anymore, but That is RPC, it screams RPC, and there is so much coupling on display that it be should be given an X-ray. This is what he's talking about. He's talking about this type of API, just something that happens to be over HTTP. but doesn't satisfy these other constraints of the RESTful architecture and in particular

the uniform interface. So We could fix this if we wanted to. We could fix this by encoding some links in the returned JSON. And so you'll see this pattern sometimes. It pains me to say that the The um Wikipedia article on uh Hadios doesn't use uh HTML. It uses it uses JSON and it gives something like this. As an example, kind of sad, but it does. So and what you would do here is you would have a Lynx field in your JSON object, and then you would have some URLs encoded in this manner that could then be uh at least make you feel like hey

you know we're encoding the actions on this thing so uh uh we're we're satisfying Hades But from a practical standpoint, if you think about this, this is being consumed by some JavaScript. consumer on the front end. What's it gonna do with these links? Is it just gonna dump them into the UI? Probably not. And this is what we found over time is that um these links have just they've been uh they've proven difficult to produce and they've uh have proven not particularly useful. The one case where I can't think that they've uh ended up being useful is in page data. I've seen libraries that use the paging links to actually to to good effect

internally just to hide from users that they have to deal with paging. which is somewhat nice, but um but it's very it's it's met with very limited success in the JSON world. And that shouldn't surprise us because JSON is uh is not uh a proper hypermedia. This is just not a hypermedia, and so it doesn't really make a lot of sense to apply REST to this world. And that's what we're seeing. That's what we're seeing the JSON uh API community stumble towards, I think. They're r r recognizing okay, REST was you know, there were some things that kinda worked with it, you know. the URL structure and using these HTTP verbs or action types.

But By and large, the Hadios in particular is just not worked out. We're not doing that. We're gonna do something else. And they've moved on and they're focusing on creating uh more x more expressive endpoints um with things like GraphQL. And so I I expect that's what the other talk that's being given on REST at this DjangoCon is about. It's saying, hey Forget about that stuff. Let's look at this tool instead and try and address some of these problems with it. And that's understandable. And I so I I applaud I applaud this uh this uh this realization that's occurring in the JSON API space. I think REST and Hadios was cargo culted

into the the JSON API world. I think once you went to a JSON API, you should be thinking RPC. And I'm not going to condemn RPC, a remote procedure call architectures. That's what Roy Fielding was discussing earlier in that quote I showed you. I'm not going to condemn that, but it's a different architecture than REST. and than the web originally was. And so those are just different things, and that's okay. They're different architectures and they have their own strengths and their own weaknesses. I do not, however, even though I think we should applaud our friends in the JSON API community for finally coming to their senses and recognizing that REST was snake oil when applied to JSON.

I don't think that that means that we should toss the concept of REST and Hadios into the dustbin. Instead, I think what we need to do is we need to think about the original model of the web. And in particular, to think about hypertext and how hypertext works, where and where REST actually works, where Any person who's just building a Web 1. 0 basic web application is building a RESTful system. Let's let's focus in there. Let's focus in there. And you might say, well, that's great, Carson, but I feel bad because I'm not building a view or a React front end and uh my my clunky old Web 1. 0 template-based, server template-based Django application kind of stinks.

It's it's not, it doesn't have the interactivity that I want. What how should we address that instead? Can that be addressed in a way that allows you to remain in the restful hateos style of architecture that the web was originally built in? And I'm glad that you asked. I'm glad that you asked. So let's think about why the these older web apps were had usability issues. And my theory, my uh my theory on this is that traditional server-rendered web apps have usability issues because HTML was never completed as a hypertext. What does that mean? Well, what that means is that HTML reached a certain point of development, and then

for whatever reasons, people moved on to other interesting stuff They never completed it. They never made it possible to issue a put from HTML, even in HTML5. Right? You can do it, but it's it's not support it's not officially supported. And so they for whatever reason they just kind of stopped pushing HTML forward as a hypertext. But Good news. And I criticize JavaScript very often, but I have to say, thanks to JavaScript, we can fix that. And in fact, we have fixed that. And we fix that with a library called HTMX. And this library attempts to address these shortcomings that have uh that have dogged

uh server-rendered template-based web applications for so long. Um and it aims to complete HTML as a hypertext, as a hypermedium. So HTMX started, it's actually fairly mature. It's enjoyed a resurgence in the last year. I rewrote this apple uh this library and renamed it. Um uh last year during the start of the COVID lockdowns. Um uh but it started back in 2013 as a library called Intercooler. js and it was based on jQuery. And so I last summer I rewrote it without any dependencies. So now it's a dependency free JavaScript library that ironically you use to avoid writing JavaScript in your web applications.

And HTMX augments HTML with custom attributes. And using these attributes, you can overcome the restrictions normally imposed on you by uh when you're doing HTML-centric development, which by definition is a restful development almost by definition. You have to try hard. You have to try pretty darn hard to do non-RESTful development if you're sticking within the HTML model. So, what does HTMX fix that's going to allow you as a Django developer to uh to stay in the original model, this original RESTful model of web development? Well Ask yourself some questions.

What's wrong with HTML? Well, one thing that's wrong with HTML, maybe, is that anchor tags and forms are the only elements that are able to interact with the server. And that seems like an unnecessary restriction. Well HTMX removes that restriction. It allows any element to make server requests. And Using attributes like hx get, hxpost, hxpost, put, or hxdelete, you can make any element on your uh in your document make a request to the server. Why should only click and submit events trigger them? That's a good question. So in normal HTML uh the only events that you can that you have available to interact with the user with are clicks on links

and then submits on forms. Those are the only two events of all the millions of events that occur in a DOM that can trigger uh an HTTP request. Well that seems a little silly. And HTMX supports uh uh a a uh an attribute hx uh trigger um that lets you specify here's another event that I want to use to trigger this request. And uh why should only get and post be available? It's somewhat crazy that in this day and age uh with with d the default HTML uh that's available to us, we can really only use get and post. We have to use uh a JavaScript in order to get access to put and delete and these other things that we want to use, right? So HTMX again kind of exposes all of this functionality to you in hypermedia.

You don't have to kick out to JavaScript to get at this stuff. You can access it right there in hypermedia using attributes. And then finally, and this is the big one, I think, from a usability standpoint, in the original HTTP and HTML model you replaced the entire screen. So if you click on a link or you submit a form, that's going to replace all the content with an entirely new document. And HTMX takes that restriction away from HTML and says, hey, you can issue a request to some URL, and then we can place the returned content from that request anywhere in the DOM. you can target an element, a different element using uh HX with the HX target attribute.

And so you can really say, hey, uh go get this bit of content and then put it into that div down there. Or whatever you want to do. And so again, HTMX expands HTML, what HTML can do by removing this restriction, by removing the restriction that the target has to always be the entire document. And so HTMX you can see really goes through these four constraints that were maybe accidentally part of the HTML when it was originally being built and just one by one removes them, giving you access to the full power. of uh HTTP and building a RESTful system within HTML using just these attributes. And so it's important to understand

that the way that HTMX works, unlike other JavaScript libraries that you might use, is it's expecting HTML back from the server. We're staying within this original model of the web where communication is happening via HTTP requests that shockingly are returning HTML. as the name might suggest. And then that HTML is swapped into the DOM. So we've really returned to this RESTful model. And at the same time, what we've done is we've allowed users within this original RESTful model to build much richer user experiences for our end users. So we are we're we're tearing apart this idea that to build good UIs you have to abandon restfulness.

We're saying no, you can build good UIs within the RESTful model. You just have to do it the uh in a different way. You have to do it in an HTML centric way. And if you do that, then you get a lot of these benefits of the older model of development, not the least of which being the simplicity of it. But you're able to stay within that model but still provide the user experience that users demand in the modern world. And you can do that in Django just as easily as any other backend. So I want to go through a couple of examples for for you so that you can see exactly what's going on here. I'm actually only going to do the first two given where my time is. But um

we'll go through the demos and I'm going to show you exactly how Hadios is working here. So let's go to examples and let's look at click to edit And I want to show you the code here. And so here we have a situation where we've got a div that's representing a contact again, my favorite example. And note that in this HTML there's a button which issues a get to a URL and it's going to target this outer div And it's going to swap the outer HTML. Don't worry too much about the attributes. This talk isn't about the details of HTMX. Rather, what I want you to focus on is I want you to focus on this concept of REST in here. So this is a very restful

situation that we've got here. We're encoding all of the actions directly in the HTML. And when you click on edit, the content that's going to come back is a form, a familiar form tag, that's going to do a put, as one might expect, maybe patch if you wanted to. quibble about things to a URL that is going to update this contact and again it's going to replace the uh this form with whatever the response is So let's go down here and look at a demo, and I want to show you what the requests look like. So this is the initial state of this demo. And when I click to edit it, I'm going to issue a get to this URL, and I'm going to get back this form, and that form has now been swapped in in the place

of that uh of that UI that we had previously of the initial state. Right? Initially we had a div and that has now been replaced with this HTML and just this HTML. Note that there's no document, there's not a full document here. We've just gotten back a snippet of HTML. And that HTML encodes all the actions that are available on this contact. Well, great. So we can update this from Joe to Joey. And we can click submit. And sure enough, we issue a put to a given URL. And we get back the new representation, the new updated representation of that resource. All very, very restful. Very very restful. And so I think you can see that this is great.

We're staying within the original model of the web But we're not our scroll state isn't getting completely, you know, nuked uh when we hit enter. It's all in line and we're able to edit do this all in line because we're we uh have HTMX. to help us drive this user interaction with the server in a way that's not available in standard HTML. So we're able to do a better UI while still sticking with this original RESTful model of the web. So that's one example and a pretty good one. An even better example because some people say, oh, that's cute, you know, HTMX might be good for a small project, but what about larger? Projects. Well,

a more significant example that I uh that I really like is Active Search And uh I show you this again, I don't want to focus too much on the details of it because th there's a a little bit here to And uh that there's a little bit more here than I'd like to go into at this point in detail, but I want to show you what is possible within the hypermedia RESTful model. So let's quickly run through this and then I just want to show you, just so you you believe me that it's possible to write very good UX in this breathful model. So here we have an input It's got a bunch of junk on it, but what it does at the end of the day is it issues a post to search. And the trigger here is on a key

up. So when a key up occurs, And it has a couple of modifiers. First of all, the input value has to change for it to issue a request. And then secondly, it's going to delay before it issues a request 500 milliseconds. And that's going to do something called debouncing this uh this request. So what that means is every time you touch type a key in this input, it's not gonna send a request. That would obviously nuke the server. We don't want to do that. And so this is an HTMX way to say, hey. Wait until the user stops typing for 500 milliseconds and then you can issue a request. We're going to target a search result div. somewhere else but something with an it might not be a div, but something with the ID search results and then there's some indicator stuff in here that you don't need to worry about just some niceties.

But what's really nice about this is here's a live demo of it. And again, we're starting with that we're starting with that HTML in this initial state. And then if I type A It's going to search and sure enough you're going to get some results back. You're going to get everyone who has an A in either their first name, last name, or email. And note that it replaced this content that was below this uh this input with all of these contacts. Pretty cool. Pretty cool. And I was able to do that just by hitting the A key in here. And if I hit E, it's gonna filter it down even further, right? And then uh what is it? A E. What are we looking at here?

A E dot. If I do AE dot, sure enough, it filters it down to anyone with apparently Vita. is in this data set. So and uh if I move the arrow key around I'm not going to be issuing requests um but if I delete I am going to issue a request. It's changed. And so this is going back to that original search. And if I do AE dot , you can see that it waited until I was finished to issue that request. It didn't issue three requests every time as I typed in. And so you can see that what's coming back again is just are just snippets of HTML. And uh using just snippets of HTML as well as some features that are available in HTMX, we're able to stain the RESTful

model and present what I hope you agree is a fairly sophisticated and dynamic user interface to the end user. Alright, don't worry too much about the details. Again, the idea here is just that using this using um hypermedia, using HTML with just a little bit more juice added to it Allows us to build some really interesting user interfaces within the RESTful model. Allows you, the Django developer, to keep using Django the way you want to. to produce this HTML from the back end, but also satisfy this need for more elaborate and more interesting user interfaces. So, HTMX and Django. All of these demos that I've shown work

great on Django. Django is a wonderful backend for producing HTML. And HTMX works great with it. And so if you use HTMX, suddenly you can use all of these tools that you are familiar with in Django that you've used for so long for producing HTML. on the server side to interact with your user. And this was a someone who took a crack at this actually recently put a tweet out saying we rebuilt a client's web app with server-side rendering. in Django plus HTMX is a proof of concept. We're 100% sold and we'll use it as our default stack in the future. Previously React. Warms my heart to see this. And I asked, and he said that it took about 25%

of the time that a normal Django and React combination takes in order to rewrite the app. just because it's with HTMX you're you're going with the grain of Django. You're using the tools that Django has built up over more than a decade to do effective server-side rendering Um and it all just works. So great. With HTMX, you can stay in that preferred backend environment. You can write Python. You don't have to write a bunch of JavaScript on the front end and then Python on the back end and have two different languages. Instead we're using the RESTful model. We're exchanging hypertext with the back end and you get to use the tools you want to use as a Django developer and still provide to your end users

excellent dynamic user experience. And so, and this is where he mentioned that uh it took about a quarter of the time. So uh what what I want to conclude with is that it's okay to not use JavaScript and JSON. I went on Python, uh I went on talk Python. And one of the comments was that people often feel bad. Django Python developers feel bad because they know they should be learning JavaScript. Well, I don't agree with that. I think that you can learn HTMX and not it's not that much code and uh you can spend most of your time in Django using the mature tools and the deep extension system. the way it was originally designed and still provide your end users excellent user experience.

You don't need to adopt a crazy JavaScript-based front end. you can use HTML. And if you do, if you do that, you're actually going to be using REST and Hadios with all the advantages that come along with that without even really thinking about it very much. You just keep doing what you're doing. um with a few new tricks uh added to HTML and uh and it you're it you're building a restful system. You're using hypertext as the engine of application state. And so I want to end end this talk with a plea that we let the web be the web. There's a time and a place for for RPC-based applications for these really crazy, highly stateful web applications that are being built today, but there's also a lot of times and places, maybe more so, where

the original web model makes more sense. It's simpler It's more dynamic and it's easier to keep stable. And with HTMX, you can provide excellent user experience even though you're staying in that model, even though you're staying in the Web 1. 0 model. And in addition to that, let's let Django be Django. Let's not turn Django into just a dumb JSON producer that just sits there wondering when Node is going to finally drop the axe on its neck. No. Django has great features. You guys love Django? Use Django. Use those great features. Don't feel like you've got to turn just turn Django into this dumb back end. that produces JSON. It doesn't have to be that way.

So this is my uh this is I I always keep this in the back of my mind when I'm working on HTMX because it's so different. But I do think it's the rest of the internet that's wrong on this stuff, guys. You're allowed to use Django and you can build great user interfaces with it. And don't feel bad. Don't feel bad And uh so I hope that this has shown you uh first of all what REST is, how it applies to Django, and how HTMX can let you build uh excellent uh user experiences while staying within that model. Thank you very much for listening and I hope you have a great day and I hope the rest of this conference treats you really well. If you have any questions or comments, you're welcome to join the HTMX

Discord My name's Carson again, but you can go to htmx. org slash discord and I'm on there pretty much all the time. And you can tell me why I'm wrong or you can agree with me or something in between those two. I'm pretty good at sport about all that stuff. All right. Have a good one. And uh thank you for listening. And again, thank you to the um to the organizers of DjangoCon for giving me a chance to explain what rest and hate us is. and uh why you might consider using it for your for your Django development. Thanks a bunch. Bye-bye.