HubSpot.Extend() Workshop 2022 | Backend Development Basics

Let's dive in to our Backend Basics refresher. We're going to review how rest APIs work, crud and different HTTP methods. So backend development, this GIF basically says it all. So on the left side here you can see front end and you see this person. They look like they're having a fun time, they're on an airplane, they might be going to a fun trip, tropical destination, looks all beautiful. And then if we see on the right side, we can see the back end, which is this man is holding a toilet seat in front of a picture of an airplane on his computer screen. So he's not actually on an airplane. So that's what back end and front end is basically. So backend development handles the behind the scenes functionality. Backend developers are focused on how a web application works, while front end developers are focused on how a web application interface looks. And so when we're using backend development, we use it to connect the web app to a database such as your HubSpot account, manage user connections, if we have a site where people are going to sign up for memberships and securely calling APIs with proper authentication measures. So you can call APIs with API keys that can, but the way that you call API keys if you're only doing front end coding is you would have to add it as a query to your URL which would expose that API key. So this is a way to Securely call your APIs without making, without having any of your important information such as your API key exposed to the front end. And so when we think about backend and front end, we can also think of it in terms of client side versus server side. Client side are all the actions that take place on the individual user's computer. And the coding usually only involves JavaScript since other programming languages are server based and someone needs an Internet connection in order for those to properly render. And this is similar to front end, server side is the actions that take place on the web server. It gives developers access to third party databases. It allows you to use server side authentication for APIs requiring that, just like we talked about. And it's similar to backend. So client side versus server side, front end versus backend, all of that is they're very similar connected ideas and it's really just about semantics when we talk about them. So if you hear someone say that they're a server side developer, that really means that they are doing a lot of the backend work, whereas if they're client side, they're going to be doing a Lot of that front end UI development work. So when we're working with backend development. All right, and so what is a REST API? I thought this was a very funny meme that I saw that kind of answers what a REST API is. So we have these two people here and they kind of put together a tandem bike, but it's not and well built tandem bike. So at the front end we have this nice green bike, looks very clean and polished. And then on the back end we have this purple looking bike that is a little, it looks a little bit older, a little bit more rusty. And that's what we consider the back end. It's not as pretty, but it gets the job done. It's going to help us move the bike forward, it's going to give us that forward momentum that we want. And then in between, to make these green and purple bikes connected, we use this, they use this duct tape. And so we can think about our REST API as being that duct tape. The REST API is going to connect our front end and our back end together and ensure and make sure that we can keep those together. And hopefully if we do it correctly, this bike is not going to fall apart as we ride it down the road. So let's talk a little bit more about what REST API means. And so REST stands for Representational State Transfer. So REST is a, is an architectural style that people follow in order to just make it so that we're following the same conventions as other people that are making these API calls as well. API stands for Application Program and Programming Interface. So the API is basically a way for you to interact with a web app such as HubSpot without having to go through the UI side. And so a REST API conforms to the constraints of the REST architectural styles. And so when we're working with APIs, there is a good acronym that we like to use. This acronym is crud. So CRUD stands for Create, Read, Update and Delete. So Create, for example, could be adding a new contact to the CRM. Read could be getting a list of contact data from the CRM, Update could be changing a contact's phone number, and Delete could be deleting a duplicate contact. So whenever we're thinking about the different ways that we can work with our APIs, these are our four main pillars that we're going to be working within. CRUD, Create, Read, Update, Delete. So now I've just created this little table for you so that we can see how CRUD interacts with the HTTP method and the REST URL so the HTTP method is whenever we use an, and whenever we use an API, we have to send, we have to send it along via a specific HTTP method. There are several different types of ATP methods, and these are some of the most basic ones and they correspond nicely with our CRED acronym. So with Create, our HTTP method is going to be post. And if we look at this rest URL, this is one of the rest URLs that you could potentially use when you're interfacing with your HubSpot account, you have CRM, which is the side of the application you're using, which is the CRM side,/v3/objects, object type and object ID. So specifically we're posting a new object type, a new object id. So it would be just like a new contact record Read is HTTP method of get. So in this one we're getting a specific contact record update. The HTTP method that we can use is patch, and for that one we can update a specific contact record. You can see, you can see how these are very connected to each other. And then delete is just delete for the ATP method, so very easy to remember. And this one we're deleting a specific contact record. So again, create, we connect with the HTTP method of post Read. HTTP method is get update. The HTTP method we're going to be using is patch, and delete is just delete for HTTP method. So very easy to remember. And throughout this workshop, we'll give you all some tutorials on how to actually use these different HTTP methods to call our APIs. So now let's break down a REST API URL. It's very important that when we're calling our API URLs that we understand how they're structured. And if we understand the structure, then we can start to understand how other APIs that we're not using are structured. And, and that makes it easier to work with them. And also it'll make it easier to work with any APIs in general if you just understand how APIs are structured. And most of them are structured in the similar way to how we do it at HubSpot. So the first thing that we have is the base URL for all the API calls we're going to make for HubSpot, that is HTTPs API.hubapi.com and just a side note, I got like a spam email the other day and, and it was like from Amazon, but I checked the base URL and it was using the API.hubapi.com URL base URL. So if you're looking at spam stuff, just check the URLs and you can find a lot of things there that will tell you, oh, this is, this is sketchy, not good. So just make sure you're always checking that you don't want to get spammed. So next, the second thing we look at in it specifically, especially in ours, is that the section of the web app we're calling, so for this one we're calling the CRM side. However, on inside of the HubSpot API suite that we have, there are the CMS side, there's the Conversations API, which is new. So all of those are considered different sections of the API that we're calling. So specifically, this one is the CRM side. The CRM side includes all of the objects, the CRM objects, properties, pipelines, those kinds of things. Then the third thing that we're doing, looking at is the version we're using. So for this one Specifically, we're using v3. We do have v1, but I do recommend that if you're using v1 endpoints, that you start to update to those v3 endpoints, because they're the newer ones and are going to be the ones that are most up to date. The next thing that we're going to be looking at is the item type that we're calling. So for this one we're using objects. Again, the CRM has a bunch of different item types that you can call. Objects is just one of those. You can also call properties, associations, pipelines, those kinds of things within the CRM side of the API. Then the last thing that we're going to call is the specific object type we're calling. So here for the objects, the object types that we can call are, are going to be contacts, companies, deals, tickets, and custom objects. And there's quite a few more. So if you want to know about all of those, you can definitely check out the API documentation on our website that has a whole list of all of the different CRM objects that you can call. And then once we have all of that, we can look at our example call and see how it all works together. So this is an actual example call. Here we're using our base URL. We're calling the CRM side of our HubSpot account. We're using version 3, we're calling the object type, the objects inside of the CRM. And then this number at the end is going to be our custom object ID number. You can also call custom object ID numbers by their fully qualified names. And the reason why we've put this into HubSpot is because if you were to create a custom object, we with similar names, we definitely do not want those names to be overlapping and cause any issues with any future things that we that you create that are custom objects. But also if we create anything, like if we decide that we want to create a new object type to add, there won't be any clashing information with those names. So we want to make sure that we're using either the custom object ID or the fully qualified name, just so we don't have any issues, and that they're always going to be extensible and usable.