API Routes: Other Handlers

[00:00:00]
>> And of course, we can add handlers for all of the other HTTP verbs as well. So we'll create a todo/ID route by creating a new folder with an ID parameter. And then inside there, create our API route. And we're gonna add a put handler and a delete handler for toggling and removing todos.

[00:00:21]
Using the toggle todo in the delete todo functions that are in the database JS file. So in here once again, we're gonna import the database. We're not importing the JSON helper at this time because we're not gonna need it. Make our put handler first, async function, put. We need the params object this time so that we know which todo we're dealing with, and then we're gonna go and grab request and cookies.

[00:01:00]
This time, the data that we're getting from the browser is gonna be a done property. And as before, we need to know the user's ID We're gonna call the toggleTodo function with that user ID, with the ID of the current todo which comes from the square brackets here.

[00:01:32]
And finally, the data itself. The response that we're gonna return this time isn't actually gonna include any data because we don't need to return any data in this context. So we'll return a new response with a null body, and a status of 204 which is no content. Add a delete handler as well, export async function delete, this time you don't even need to look at the request.

[00:02:04]
So we're just gonna get params and cookies, get the user ID, And then we'll call database.deleteTodo, pass in user ID, pass in the ID from the params object. And again, we're gonna return an empty response. Okay, so we can now interact with this endpoint inside our event handlers.

[00:02:39]
First, we'll add one inside the onChange handler of the checkbox on the left. Scroll down to where that is, see the onChange handler here. We're gonna call fetch, and this time we're gonna pass in the ID of the todo as part of the URL, so that it becomes available on the params object.

[00:03:07]
The method for this one is put corresponding to the put verb that we just defined. And the data that we're passing is whether or not the todo is done, then once again, Content-Type, application/json. And then on the other side of the todo when the button gets clicked, we're gonna post a delete request to our handler.

[00:03:49]
I'm gonna send the request to the same place. This time we don't need a body, the request itself is enough. And once that request succeeds, we'll again mutate the array this time to remove the one that we no longer need. Do that by filtering on whether the member of the array is the current todo.

[00:04:23]
Okay, so we can now mark todos as complete, if I refresh the page that should stay checked and we can also delete them and if I refresh the page that should stay deleted. Okay, so that was a lot more work than using a form action and it won't work without JavaScript.

[00:04:40]
So I do recommend using form actions where possible, but this is an option that you have when you need it. Okay, so we got a question about whether or not it makes sense to put the logic in an API route handler. Or in a server module inside your lib directory.

[00:04:58]
And the answer is that you cannot call functions on the server directly from within a page.svelte, you have to go via an API route or via a form action, unless you've set up something like a third party library like Telefunc or something that allows you to do some sort of RPC mechanism.

[00:05:18]
And so there really is no distinction there. You're gonna put some logic in your API handlers, but very often, you'll have some kind of an abstraction similar to our database JS file here, where the actual database manipulation is happening. And your API routes will just be calling these helper methods.

[00:05:40]
But there's always gonna be some logic in an API route handler. I hope that answers the question.
>> Let's say I want my endpoints to be used later for a mobile app is that okay, or would I need rewrite the API?
>> Absolutely, these endpoints, they are public HTTP endpoints, and if you disable the default cross-site request forgery protection, then you can use it as a regular public API.

[00:06:13]
You can use it within your app. And you can make fetch calls against your own endpoints inside your load functions, and that'll work without issuing an HTTP call. So you can build an API that way and make it public but also privately accessible. And that just works. But the default assumption when you're building a SvelteKit app is that the API routes and the server load functions are specifically for the pages that you're building.

[00:06:41]
So it's entirely up to you if you want to deviate from that and open up your API to the world.
>> I could just import function from lib utils.ts to get a function to do the same things like, add, remove information from a database etc. So what I want to do that or implement API endpoints.

[00:07:01]
>> So if you're importing the file inside your page.svelt, then that implies that that file is available in the client, and if you're doing that, then you don't have direct access to a database, you need to go through some HTTP layer in order to interact with your back-end.

[00:07:19]
Later we'll learn about server modules which cannot be imported into a page.svelte file, which prevents you from making that error. So yeah, you're not gonna be able to directly manipulate the database from within your component. That is a deliberate design decision. We don't let you do that because that way, insecurity and madness lies.

[00:07:41]
So, yeah, you're always gonna be going through API routes or form actions when you wanna mutate data on the server.