Laravel API开发？API路由如何定义？-Laravel-PHP中文网

Laravel通过routes/api.php定义API路由，使用Route::apiResource或HTTP动词方法声明端点，由RouteServiceProvider自动添加/api前缀和api中间件组，确保无状态处理。与web.php的Web路由不同，API路由不依赖Session和CSRF，返回JSON数据，适用于SPA或移动端。常用认证方式包括Laravel Sanctum（推荐用于Token认证）、Passport（支持OAuth2）和Basic Auth。异常处理在App\Exceptions\Handler.php中统一管理，针对API请求返回标准化JSON错误响应，如422验证失败、404资源未找到等，提升API可用性。

laravel api开发？api路由如何定义？

在Laravel中，定义API路由的核心在于使用

routes/api.php

登录后复制

文件，通过

Route::apiResource

登录后复制

或

Route::get/post/put/delete

登录后复制

等方法来声明API端点，并由

RouteServiceProvider

登录后复制

确保这些路由应用了

api

登录后复制

中间件组，从而实现无状态的认证和处理。

Laravel API的路由定义其实蛮直接的，主要围绕

routes/api.php

登录后复制

这个文件展开。当你创建一个新的Laravel项目时，这个文件就躺在那里了。默认情况下，

RouteServiceProvider

登录后复制

会为

routes/api.php

登录后复制

中的所有路由加上一个

/api

登录后复制

的前缀，并且应用

api

登录后复制

中间件组。这个

api

登录后复制

中间件组很关键，它确保了你的API路由是无状态的，通常不使用session，而是依赖token进行认证。

定义路由的方式和Web路由类似，但侧重点不同：

单个路由定义：你可以像定义Web路由一样，使用

Route::get()

登录后复制

、

Route::post()

登录后复制

、

Route::put()

登录后复制

、

Route::delete()

登录后复制

等方法来定义具体的API端点。

// routes/api.php
Route::get('/products', [ProductController::class, 'index']);
Route::post('/products', [ProductController::class, 'store']);
Route::get('/products/{product}', [ProductController::class, 'show']);
// ...以此类推

登录后复制

这种方式灵活，适合定义非标准RESTful的接口，或者一些特殊的操作。

API资源路由：对于遵循RESTful规范的资源，Laravel提供了
```
Route::apiResource()
```
登录后复制
方法，它会自动生成一套标准的CRUD（创建、读取、更新、删除）路由，但与
```
Route::resource()
```
登录后复制
不同的是，它不会生成
```
create
```
登录后复制
和
```
edit
```
登录后复制
视图相关的路由，因为API通常不需要这些。
```
// routes/api.php
Route::apiResource('posts', PostController::class);
// 这会生成 /api/posts (GET, POST), /api/posts/{post} (GET, PUT, DELETE) 等路由
```
登录后复制
我个人非常喜欢
```
apiResource
```
登录后复制
，它能大幅减少样板代码，让路由定义看起来非常清晰。当然，如果你需要排除或只包含某些操作，也可以通过
```
except
```
登录后复制
或
```
only
```
登录后复制
方法来定制。

路由分组与版本控制：随着API的演进，你可能需要对路由进行分组，比如按版本来分。这时候

Route::prefix()

登录后复制

和

Route::middleware()

登录后复制

就派上用场了。

// routes/api.php
Route::prefix('v1')->group(function () {
    Route::apiResource('users', UserController::class);
    Route::get('/dashboard-stats', [DashboardController::class, 'stats']);
});

Route::prefix('v2')->group(function () {
    // v2版本的路由
    Route::apiResource('users', UserV2Controller::class);
});

登录后复制

这种方式让不同版本的API共存，也方便管理。

认证中间件：别忘了，API通常需要认证。你可以在路由定义时直接应用认证中间件，比如使用Laravel Sanctum的

auth:sanctum

登录后复制

。

// routes/api.php
Route::middleware('auth:sanctum')->group(function () {
    Route::get('/user', function (Request $request) {
        return $request->user();
    });
    Route::apiResource('orders', OrderController::class);
});

登录后复制

这确保了只有经过认证的用户才能访问这些端点。

总的来说，Laravel在API路由方面提供了非常灵活且强大的工具集，你可以根据项目的具体需求，选择最适合的方式来定义和组织你的API。

Laravel API路由与Web路由有何不同？

这是个很基础但又经常被问到的问题，尤其对于刚接触Laravel API开发的朋友。简单来说，API路由和Web路由在Laravel中，虽然都定义在

routes

登录后复制

目录下，但它们的设计哲学和处理方式有着本质的区别。

最直观的区别在于它们各自的文件：API路由通常定义在

routes/api.php

登录后复制

，而Web路由则在

routes/web.php

登录后复制

。但这只是表象。

核心差异在于它们所使用的中间件组。

newasp框架2.3.0

newasp框架是一个基于 Classic Asp Vbscript Api 框架。全面支持64位，无需修改应用池32位启用，效率更高。更新日志： 8月2号 - v2.2.9 修复Str.ToString对GetRows二维数组的解析问题 7月26号 - v2.2.8 修复IIS在前端自定义信息头提交下的跨域访问问题修复路由对跨域OPTIONS发起提交导致的访问问题修改web.confi

查看详情

routes/web.php

登录后复制

中的路由默认应用

web

登录后复制

中间件组。这个中间件组包含了像

StartSession

登录后复制

（启动会话）、

ShareErrorsFromSession

登录后复制

（分享错误到会话）、

VerifyCsrfToken

登录后复制

（CSRF保护）等一系列为传统Web应用设计的中间件。这意味着Web路由是有状态的，它依赖Session来维护用户状态，并提供CSRF保护以防止跨站请求伪造攻击。当用户访问Web页面时，Laravel会返回HTML，并可能设置或读取Session数据。

而

routes/api.php

登录后复制

中的路由默认应用

api

登录后复制

中间件组。这个中间件组则轻量得多，它通常只包含

ThrottleRequests

登录后复制

（请求限流）和

SubstituteBindings

登录后复制

（路由模型绑定）等，最重要的是，它不包含Session和CSRF相关的中间件。这使得API路由是无状态的，它们不依赖Session来维护用户状态。API通常返回JSON或其他数据格式，供前端应用（如SPA、移动App）或第三方服务消费。认证机制也多采用基于Token的方式，比如JWT、OAuth2或Laravel Sanctum生成的API Token。

我个人的经验是，很多新手会不小心把API路由定义到

web.php

登录后复制

里，或者把

web

登录后复制

中间件组应用到API路由上。这虽然在某些情况下也能“跑起来”，但很快就会遇到问题，比如Session冲突、不必要的CSRF验证失败，或者性能下降。所以，保持API和Web路由的职责分离，用好各自的中间件组，是构建健壮Laravel应用的关键。API就应该纯粹地处理数据交互，Web就应该专注于用户界面和会话管理。

Laravel API路由中常用的认证方式有哪些？

在Laravel API的生态中，认证是确保API安全的关键一环。毕竟，你不会想让任何人都能随意访问你的数据。Laravel提供了几种非常流行且强大的认证方式，可以根据你的项目需求来选择。

Laravel Sanctum (最推荐的轻量级方案) 这是我个人在大多数新项目中首选的API认证方案，因为它轻巧、易用，且功能强大。Sanctum主要解决了三种场景的认证需求：
1. SPA认证：当你的前端是独立的SPA（单页应用，如Vue、React）时，Sanctum通过Cookie来管理认证，但它与传统的Session认证不同，它会利用CSRF Token来保护API请求，并提供一个安全的认证流程。
2. 移动应用/简单API Token：对于移动应用或需要简单API Token的场景，Sanctum允许你为用户生成API Token。这些Token可以存储在客户端，并在每次请求时通过
```
Authorization: Bearer <token>
```
  登录后复制
  头发送。Sanctum会验证这个Token的有效性。
3. 个人访问令牌：用户可以生成多个个人访问令牌，并为每个令牌分配特定的权限（Scopes）。这对于允许第三方应用访问用户数据，但又想精细控制权限的场景非常有用。
Sanctum的优势在于它的简洁性和灵活性，对于大多数API项目来说，它都是一个非常好的起点。
Laravel Passport (OAuth2完整实现) 如果你的API需要支持OAuth2协议，或者你想构建一个为第三方应用提供服务的API，那么Passport就是你的不二之选。Passport是Laravel官方提供的OAuth2服务器实现，它能让你轻松地为你的API添加以下OAuth2特性：
1. 授权码授权 (Authorization Code Grant)：用于第三方应用安全地获取用户授权。
2. 密码授权 (Password Grant)：适用于你自己的第一方客户端应用（如移动App）。
3. 客户端凭证授权 (Client Credentials Grant)：适用于机器对机器的通信。
4. 隐式授权 (Implicit Grant)：虽然安全性较低，但在某些特定场景下仍有使用。
5. 个人访问令牌 (Personal Access Tokens)：与Sanctum类似，但基于OAuth2标准。
Passport的功能非常强大，但相对Sanctum来说，配置和理解会稍微复杂一些。如果你的项目需要完整的OAuth2功能，或者你预计会有大量的第三方集成，那么投入时间学习Passport是值得的。
Basic Authentication (HTTP基本认证) 虽然不太常见于生产环境的公共API，但HTTP基本认证在某些内部系统或特定场景下仍有应用。它通过在请求头中发送Base64编码的用户名和密码来认证。Laravel可以通过自定义中间件或利用
```
Auth::basic()
```
登录后复制
方法来支持。它的缺点是安全性相对较低，因为凭据是直接编码发送的，容易被截获。

选择哪种认证方式，真的取决于你的API服务对象和安全需求。对于大多数只需要简单API Token的移动App或SPA后端，Sanctum是极佳的选择。如果你的API是一个平台，需要让其他开发者构建应用，那么Passport的OAuth2能力会是必需品。

Laravel API路由中如何处理异常和错误响应？

处理API中的异常和错误响应，不仅仅是让程序不崩溃那么简单，它更是提供良好API用户体验的关键。一个设计糟糕的错误响应，比一个直接500的响应还要令人抓狂，因为它让调用者不知道如何处理。Laravel在这个方面做得非常出色，提供了强大的机制来统一处理异常并返回友好的JSON错误响应。

核心在于Laravel的

App\Exceptions\Handler.php

登录后复制

文件。这个类是所有未捕获异常的“最终归宿”。你可以重写其中的

render

登录后复制

方法来定制不同类型异常的HTTP响应。

1. 统一的错误响应格式： 我通常会定义一个统一的JSON错误响应结构。这样，无论出现什么错误，调用者都能预期接收到类似格式的数据，便于前端或客户端进行解析和处理。一个常见的格式可能包含

message

登录后复制

、

errors

登录后复制

（详细错误信息，通常是验证错误）、

code

登录后复制

（内部错误码，可选）和

status

登录后复制

（HTTP状态码）。

// App\Exceptions\Handler.php

use Illuminate\Validation\ValidationException;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
use Throwable;

public function render($request, Throwable $exception)
{
    if ($request->is('api/*')) { // 仅对API请求进行JSON错误响应
        if ($exception instanceof ValidationException) {
            return response()->json([
                'message' => 'The given data was invalid.',
                'errors' => $exception->errors(),
            ], 422); // 422 Unprocessable Entity
        }

        if ($exception instanceof NotFoundHttpException) {
            return response()->json([
                'message' => 'Resource not found.',
            ], 404); // 404 Not Found
        }

        // 更多自定义异常处理...

        // 默认的服务器错误
        return response()->json([
            'message' => 'Server Error.',
            // 生产环境不应该暴露详细错误信息
            // 'debug' => config('app.debug') ? $exception->getMessage() : null,
        ], 500); // 500 Internal Server Error
    }

    return parent::render($request, $exception);
}

登录后复制

2. 利用HTTP状态码： 正确使用HTTP状态码至关重要。它们是API与客户端之间沟通错误性质的通用语言。

```
200 OK
```
登录后复制
：请求成功。
```
201 Created
```
登录后复制
：资源创建成功。
```
400 Bad Request
```
登录后复制
：客户端发送的请求有语法错误，服务器无法理解。
```
401 Unauthorized
```
登录后复制
：请求需要用户认证。
```
403 Forbidden
```
登录后复制
：服务器理解请求，但拒绝执行。
```
404 Not Found
```
登录后复制
：请求的资源不存在。
```
405 Method Not Allowed
```
登录后复制
：请求方法不被允许。
```
422 Unprocessable Entity
```
登录后复制
：客户端发送的数据验证失败（Laravel的
```
ValidationException
```
登录后复制
默认会返回这个）。
```
500 Internal Server Error
```
登录后复制
：服务器内部错误。

3. 自定义异常类： 对于应用程序特有的错误，创建自定义异常类是个好习惯。这样，你可以在业务逻辑中抛出这些异常，然后在

Handler.php

登录后复制

中捕获并返回特定的JSON响应。

// App/Exceptions/ProductNotFoundException.php
namespace App\Exceptions;

use Exception;
use Illuminate\Http\JsonResponse;

class ProductNotFoundException extends Exception
{
    public function render($request): JsonResponse
    {
        return response()->json([
            'message' => 'Product not found with the given ID.',
            'code' => 'PRODUCT_001'
        ], 404);
    }
}

// 在控制器或服务中抛出
throw new ProductNotFoundException();

登录后复制

4. 验证错误处理： Laravel的表单请求（Form Requests）在验证失败时，会自动抛出