		<div class="wpcnt">
			<div class="wpa">
				<span class="wpa-about">Advertisements</span>
				<div class="u top_amp">
							<amp-ad width="300" height="265"
		 type="pubmine"
		 data-siteid="173035871"
		 data-section="1">
		</amp-ad>
				</div>
			</div>
		</div><p dir="ltr">To build a REST API in 2026, install Node.js 22.18 or later, Express 5, and TypeScript, then write route handlers that validate input and return correct HTTP status codes. Node can now run TypeScript files directly by stripping types, so you no longer need ts-node for simple projects. This guide walks through setup, a small CRUD API, validation with Zod, error handling, and status codes. It also flags what changed since older tutorials: Express 5 handles rejected promises for you, and TypeScript 7 has stricter defaults.</p>
<h2 dir="ltr">What Changed Since the Old Tutorials</h2>
<h3 dir="ltr"><strong>TypeScript 7</strong></h3>
<p dir="ltr">Microsoft&#8217;s announcement says TypeScript 7.0 is &#8220;a 10x faster native port,&#8221; written in Go, and the command is still tsc. TypeScript 6.0, released March 23, 2026, was the last JavaScript-based version. The post lists breaking changes: strict now defaults to true, module defaults to esnext, and options like target es5, baseUrl, and the older node module resolution modes are hard errors. There is no programmatic API until 7.1, so tools like typescript-eslint use a compatibility package. As of October 17, 2026, the npm registry listed TypeScript 7.0.2.</p>
<h3 dir="ltr"><strong>Node Runs TypeScript Directly</strong></h3>
<p dir="ltr">Node&#8217;s documentation marks type stripping as stable. It is on by default since versions 23.6.0 and 22.18.0, stable in 25.2.0 and 24.12.0, and prints no warning since 24.3.0. The limits matter: it does no type checking, enums, runtime namespaces, and parameter properties cause errors, tsconfig paths are ignored, imports need the .ts extension, type imports need the type keyword, and .tsx and files under node_modules are not supported.</p>
<h3 dir="ltr"><strong>Express 5</strong></h3>
<p dir="ltr">Express 5 requires Node 18 or higher. The npm latest tag for express was 5.3.0, published October 9, 2026, with a latest-4 tag at 4.22.3. Express&#8217;s migration guide says handlers and middleware that return rejected promises now forward the error to error middleware automatically. It also notes that req.body is undefined when unparsed, that app.del() and req.param() are removed, and that wildcards need a name, such as /*splat.</p>
<h3 dir="ltr"><strong>Which Node Version?</strong></h3>
<p dir="ltr">The Node.js release pages list v24 as Active LTS and v26 as Current, first released May 5, 2026. The release schedule says v26 enters LTS on October 28, 2026, and Node 24 enters maintenance on October 20, 2026. Node 20 is end-of-life. Use an LTS version for anything you deploy.</p>
<h2 dir="ltr">Step 1: Set Up the Project</h2>
<p dir="ltr">Following Express&#8217;s installation guide, create a folder and initialize it, then install packages. The commands are mkdir myapp, cd myapp, npm init, npm install express, and npm install &#8211;save-dev typescript @types/express @types/node. Add Zod with npm install zod. Zod&#8217;s documentation says it is tested against TypeScript 5.5 or newer and that you must enable strict mode.</p>
<h3 dir="ltr"><strong>A tsconfig for Node</strong></h3>
<p dir="ltr">Node&#8217;s documentation recommends this configuration for TypeScript 5.8 or newer, which is used here for type checking only:</p>
<div dir="ltr" tabindex="0" role="group" aria-label="Code">
<div>
<div></div>
</div>
<div>
<pre><code>{ 
 "compilerOptions": { 
 "noEmit": true, 
 "target": "esnext", 
 "module": "nodenext", 
 "rewriteRelativeImportExtensions": true, 
 "erasableSyntaxOnly": true, 
 "verbatimModuleSyntax": true 
 } 
}</code></pre>
</div>
</div>
<p dir="ltr">The erasableSyntaxOnly setting makes TypeScript flag syntax that type stripping cannot handle, such as enums. Run npx tsc to check types, and run the app with node app.ts. Express&#8217;s own docs say running TypeScript directly needs Node 22.18.0 or newer (or 23.6.0 or newer) and TypeScript 5.8 or newer.</p>
<h2 dir="ltr">Step 2: Hello World</h2>
<p dir="ltr">This is the official Express example, written in CommonJS:</p>
<div dir="ltr" tabindex="0" role="group" aria-label="Code">
<div>
<div></div>
</div>
<div>
<pre><code>const express = require('express'); 
const app = express(); 
const port = 3000; 
 
app.get('/', (req, res) =>; { 
 res.send('Hello World!'); 
}); 
 
app.listen(port, () =>; { 
 console.log(`Example app listening on port ${port}`); 
});</code></pre>
</div>
</div>
<p dir="ltr">In a TypeScript file you would use import syntax instead, with the type keyword for type-only imports, and the filename would end in .ts. Run it, open the browser to port 3000, and you should see the greeting.</p>
<h2 dir="ltr">Step 3: Design the Resource</h2>
<p dir="ltr">REST organizes an API around resources. For a list of users, a typical layout is a GET request on the users collection to list, a POST on the same path to create, a GET on a single user path to read, a PUT or PATCH to update, and a DELETE to remove. Keep paths as nouns, not verbs.</p>
<h2 dir="ltr">Step 4: Validate Input With Zod</h2>
<p dir="ltr">Never trust a request body. Zod&#8217;s documentation shows the pattern: define a schema, then parse input against it. For example, a schema built with z.object and a name field of z.string() is used by calling its parse method on the input. When parsing fails, it throws an error you can turn into a 400 or 422 response. Remember that Express 5 leaves req.body undefined unless you add the JSON body parser middleware, so enable it first and check for a missing body.</p>
<h2 dir="ltr">Step 5: Use the Right Status Codes</h2>
<p dir="ltr">MDN&#8217;s reference gives these meanings: 200 OK; 201 Created, &#8220;typically the response sent after POST&#8221;; 204 No Content; 400 Bad Request; 401, &#8220;semantically &#8230; unauthenticated&#8221;; 403 Forbidden; 404 Not Found; 409 Conflict; 422 Unprocessable Content; and 500 Internal Server Error. A reasonable pattern is 201 after creating, 204 after deleting, 400 for malformed requests, 404 when the resource is missing, and 409 when it conflicts with existing data.</p>
<h2 dir="ltr">Step 6: Handle Errors</h2>
<p dir="ltr">With Express 5, an async handler can simply throw or reject, and the error reaches your error middleware. Express&#8217;s documentation shows this pattern:</p>
<div dir="ltr" tabindex="0" role="group" aria-label="Code">
<div>
<div></div>
</div>
<div>
<pre><code>app.get('/user/:id', async (req, res) =>; { 
 const user = await getUserById(req.params.id); 
 res.send(user); 
}); 
 
function errorHandler(err, req, res, next) { 
 if (res.headersSent) { 
 return next(err); 
 } 
 res.status(500); 
 res.render('error', { error: err }); 
}</code></pre>
</div>
</div>
<p dir="ltr">The documentation also says the response status is set from err.status or err.statusCode, and &#8220;If this value is outside the 4xx or 5xx range, it will be set to 500.&#8221; For a JSON API, send a JSON body instead of rendering a page, and never leak stack traces to clients.</p>
<h2 dir="ltr">Step 7: Organize Your Code</h2>
<p dir="ltr">Keep routes, validation schemas, and business logic in separate files. A common layout has a routes folder, a schemas folder, and a services folder. This article does not claim a standard, since the sources reviewed do not prescribe one.</p>
<h2 dir="ltr">Testing Your API</h2>
<p dir="ltr">Use a tool such as curl or an HTTP client extension to send requests and check responses. Test the unhappy paths: missing fields, wrong types, unknown ids. The sources reviewed do not cover testing frameworks, so this article does not recommend one.</p>
<h2 dir="ltr">Security Basics</h2>
<p dir="ltr">Validate all input, limit body size, and use HTTPS in production. Do not log secrets. Keep dependencies updated. The research for this article did not review authentication libraries, so choose one after reading its current documentation.</p>
<h2 dir="ltr">Deployment</h2>
<p dir="ltr">Pick an LTS Node version, install dependencies, set environment variables, and run with a process manager or container. The free hosting options in our deployment guide may suit hobby projects.</p>
<h2 dir="ltr">Project Structure That Scales</h2>
<p dir="ltr">A small API can live in one file, but a slightly larger one benefits from separation. Keep route definitions in one module, validation schemas in another, and data access in a third. That way, when you swap the in-memory store for a database, only one module changes. The sources reviewed do not prescribe a layout, so treat this as a common-sense suggestion, not a rule from Express&#8217;s documentation.</p>
<h2 dir="ltr">Handling Validation Errors Cleanly</h2>
<p dir="ltr">When a Zod parse fails, return a 400 or 422 with a message the client can use, and do not leak internal details. MDN describes 422 as Unprocessable Content, which suits a request that is well formed but has invalid values, while 400 suits one that is malformed. Pick one convention and document it, so API consumers know what to expect. In Express 5, you can throw from an async handler and let your error middleware format the response, which keeps handlers short.</p>
<h2 dir="ltr">Checking Your Setup After Upgrading</h2>
<p dir="ltr">Because TypeScript 7 changed defaults, a project that compiled under older settings may produce errors. The release post says strict now defaults to true, module defaults to esnext, and several old options are hard errors, including target es5 and baseUrl. If you hit these, update tsconfig rather than turning checks off. Also note the compatibility detail for tooling: until version 7.1 there is no programmatic API, so linters that depend on it use a compatibility package. If an editor integration breaks after an upgrade, check whether it relies on that API.</p>
<h2 dir="ltr">A Short Reading Order for Beginners</h2>
<p dir="ltr">If you are new to all three technologies, learn them in this order. First, plain Node with a simple script, using the stable type stripping in a current LTS release. Second, Express with a single route, such as the hello world example. Third, TypeScript types for request and response bodies, checked with npx tsc. Fourth, Zod for validation. Fifth, error middleware. Each step adds one idea, and each can be tested before the next.</p>
<h2 dir="ltr">Express 5 Gotchas to Remember</h2>
<p dir="ltr">Express 5 changed several things that older tutorials get wrong. Wildcard routes need a name, such as /*splat. The app.del() and req.param() methods are removed. The req.body property is undefined unless you use a body parser. And the node version floor is 18. If a tutorial code sample fails with a path-pattern error, the wildcard rule is the most likely cause.</p>
<h2 dir="ltr">Staying Current</h2>
<p dir="ltr">Node and TypeScript move quickly. As of October 17, 2026, the schedule shows Node 24 entering maintenance on October 20, 2026 and Node 26 entering LTS on October 28, 2026, so use an LTS release when starting a project. Check the TypeScript release notes before upgrading, since version 7 changes defaults. Pin versions in package.json so your builds are repeatable.</p>
<h2 dir="ltr">From In-Memory to Real Database</h2>
<p dir="ltr">A tutorial API often keeps data in an array, which resets whenever the server restarts. When you outgrow that, add a database through a module that your routes call, so the route code does not change. The free database options covered in our hosting guide are a starting point for prototypes. The research for this article did not review database libraries for Node, so choose one after reading its current documentation, and confirm that it supports your TypeScript version.</p>
<h2 dir="ltr">Deploying With Confidence</h2>
<p dir="ltr">Before deploying, check that your build runs from a clean install, that environment variables are set on the host, and that you use an LTS Node version. Run npx tsc as a check step in your build, since type stripping at runtime does not check types. Add a simple health route that returns 200, so hosting platforms and monitors can confirm the service is running. Log errors with enough context to debug, without logging secrets or personal data.</p>
<h2 dir="ltr">Frequently Asked Questions</h2>
<h3 dir="ltr">Do I still need ts-node?</h3>
<p dir="ltr">For simple projects, no. Node&#8217;s stable type stripping runs .ts files directly. The npm registry shows ts-node 10.9.2 last published in December 2023.</p>
<h3 dir="ltr">Should I use Express 5 or 4?</h3>
<p dir="ltr">Express 5 is the npm latest. It forwards async errors to error middleware. The latest-4 tag is 4.22.3.</p>
<h3 dir="ltr">Does Node type-check my TypeScript?</h3>
<p dir="ltr">No. Type stripping removes types without checking. Run npx tsc for checks.</p>
<h3 dir="ltr">Which status code should POST return?</h3>
<p dir="ltr">201 Created, typically, per MDN.</p>
<h3 dir="ltr">Which Node version should I use?</h3>
<p dir="ltr">An LTS release. Node 24 is LTS, and Node 26 becomes LTS on October 28, 2026.</p>
<h2 dir="ltr"><strong>References and Sources</strong></h2>
<p dir="ltr">Node.js, &#8220;Previous Releases&#8221;: <a href="https://nodejs.org/en/about/previous-releases">https://nodejs.org/en/about/previous-releases</a></p>
<p dir="ltr">Node.js, &#8220;Download&#8221;: <a href="https://nodejs.org/en/download">https://nodejs.org/en/download</a></p>
<p dir="ltr">GitHub, &#8220;nodejs/Release&#8221;: <a href="https://github.com/nodejs/Release">https://github.com/nodejs/Release</a></p>
<p dir="ltr">Node.js, &#8220;End-of-life releases&#8221;: <a href="https://nodejs.org/en/about/eol">https://nodejs.org/en/about/eol</a></p>
<p dir="ltr">Node.js Docs, &#8220;Modules: TypeScript&#8221;: <a href="https://nodejs.org/api/typescript.html">https://nodejs.org/api/typescript.html</a></p>
<p dir="ltr">Microsoft, &#8220;Announcing TypeScript 7.0&#8221;: <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/">https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/</a></p>
<p dir="ltr">Express, &#8220;Migrating to Express 5&#8221;: <a href="https://expressjs.com/en/guide/migrating-5.html">https://expressjs.com/en/guide/migrating-5.html</a></p>
<p dir="ltr">Express, &#8220;Error handling&#8221;: <a href="https://expressjs.com/en/guide/error-handling.html">https://expressjs.com/en/guide/error-handling.html</a></p>
<p dir="ltr">Express, &#8220;Installing&#8221;: <a href="https://expressjs.com/en/starter/installing.html">https://expressjs.com/en/starter/installing.html</a></p>
<p dir="ltr">Express, &#8220;Hello world example&#8221;: <a href="https://expressjs.com/en/starter/hello-world.html">https://expressjs.com/en/starter/hello-world.html</a></p>
<p dir="ltr">Zod, &#8220;Zod documentation&#8221;: <a href="https://zod.dev/">https://zod.dev/</a></p>
<p dir="ltr">MDN, &#8220;HTTP response status codes&#8221;: <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status">https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status</a></p>

How to Build a REST API with Node.js, Express, and TypeScript in 2026
How to Build a REST API with Node.js, Express, and TypeScript in 2026