Lỗi cú pháp, không mong muốn ':', mong đợi hoặc laravel

câu trả lời được chấp nhận

Đây là mã đầy đủ được cập nhật với những thay đổi. Vui lòng tham khảo điều này

Bộ điều khiển. php

public function serviceOverview[Request $request]
{
    $builder = DB::table["service_package"]
                    ->join['services', 'services.id', '=', 'service_package.service_id']
                    ->join['service_type', 'service_type.id', '=', 'services.service_type']
                    ->select['service_package.title as service_id', 'service_package.title as package_name', DB::raw["DATE[service_package.created_at] as created_at"], 'service_package.price', 'service_package.days','services.name as service_name','service_type.name as service_type'];

    if[$request->filled['package_name']]] {

        $builder = $builder->where['serviceoverviews','like','%'.$request->serviceoverviews.'%'];
    }    

    if[isset[$request->service_id]]
    {
        $builder=$builder->where['service_id',$request->service_id];
    }

    $serviceoverviews = $builder->orderBy['created_at','DESC']->paginate[15];

    $data = [
        'title' => 'Subscription Overview',
        'serviceoverviews' => $serviceoverviews
    ];

    return view['report.serviceOverview', $data];
}

Bây giờ hãy thay đổi mã xem của bạn như thế này

lượt xem. lưỡi. php

        @foreach[$serviceoverviews as $key => $serviceoverview]
            

        @endforeach
        
    
    
        
            #
            Service
            Package
            Service Type
            Date
            Price
            Days

        
    

    
                {{ ++$key }}
                {{ $serviceoverview->service_name }}
                {{ $serviceoverview->package_name }}
                {{ $serviceoverview->service_type }}
                {{ serviceoverview->created_at }}
                {{ $serviceoverview->price }}
                {{ $serviceoverview->days }}                
            
            
                {{ $serviceoverview->appends[\Request::all[]]->links[] }}
            
                 
    

Lỗi là khá rõ ràng. Bạn nên bỏ dấu chấm phẩy. Bạn nên xóa dấu chấm phẩy tồn tại trước dấu ngoặc đơn đóng của phương thức whereHas[]

Đăng nhập để tham gia vào chủ đề này

API REST sử dụng phần Dòng trạng thái của thông báo phản hồi HTTP để thông báo cho khách hàng về kết quả bao quát của yêu cầu của họ. RFC 2616 định nghĩa cú pháp Dòng trạng thái như hình bên dưới

Dòng trạng thái = HTTP-Phiên bản SP Mã trạng thái SP Lý do-Cụm từ CRLF

HTTP xác định các mã trạng thái tiêu chuẩn này có thể được sử dụng để truyền đạt kết quả yêu cầu của khách hàng. Các mã trạng thái được chia thành năm loại

• 1xx. Thông tin – Truyền đạt thông tin cấp giao thức truyền
• 2xx. Thành công – Cho biết rằng yêu cầu của khách hàng đã được chấp nhận thành công
• 3xx. Chuyển hướng – Cho biết rằng khách hàng phải thực hiện một số hành động bổ sung để hoàn thành yêu cầu của họ
• 4xx. Lỗi máy khách – Loại mã trạng thái lỗi này chỉ ngón tay vào máy khách
• 5xx. Lỗi máy chủ – Máy chủ chịu trách nhiệm về các mã trạng thái lỗi này

1xx Mã trạng thái [Thông tin]

Mã trạng thái

Sự mô tả

100 Tiếp tục

Một phản ứng tạm thời. Cho khách hàng biết rằng phần đầu tiên của yêu cầu đã được nhận và chưa bị máy chủ từ chối. Máy khách NÊN tiếp tục bằng cách gửi phần còn lại của yêu cầu hoặc, nếu yêu cầu đã được hoàn thành, hãy bỏ qua phản hồi này. Máy chủ PHẢI gửi phản hồi cuối cùng sau khi yêu cầu đã được hoàn thành

101 Giao thức chuyển mạch

Được gửi để phản hồi tiêu đề yêu cầu Nâng cấp từ máy khách và cho biết giao thức mà máy chủ đang chuyển sang

102 Xử lý [WebDAV]

Cho biết máy chủ đã nhận và đang xử lý yêu cầu nhưng chưa có phản hồi

103 gợi ý ban đầu

Chủ yếu được sử dụng với tiêu đề Link. Nó đề xuất tác nhân người dùng bắt đầu tải trước tài nguyên trong khi máy chủ chuẩn bị phản hồi cuối cùng

2xx Mã trạng thái [Thành công]

Mã trạng thái

Sự mô tả

200 được

Cho biết yêu cầu đã thành công

201 đã tạo

Cho biết rằng yêu cầu đã thành công và kết quả là một tài nguyên mới đã được tạo

202 Được chấp nhận

Cho biết rằng yêu cầu đã được nhận nhưng chưa được hoàn thành. Nó thường được sử dụng trong các yêu cầu chạy nhật ký và xử lý hàng loạt

203 Thông tin không có thẩm quyền

Cho biết rằng siêu thông tin được trả về trong tiêu đề thực thể không phải là tập hợp cuối cùng có sẵn từ máy chủ gốc, nhưng được thu thập từ bản sao cục bộ hoặc bên thứ ba. Tập hợp được trình bày CÓ THỂ là tập hợp con hoặc tập hợp phụ của phiên bản gốc

204 Không Có Nội Dung

Máy chủ đã hoàn thành yêu cầu nhưng không cần trả lại nội dung phản hồi. Máy chủ có thể trả lại thông tin meta đã cập nhật

205 Đặt lại nội dung

Cho biết khách hàng đặt lại tài liệu đã gửi yêu cầu này

206 Nội dung một phần

Nó được sử dụng khi tiêu đề Range được gửi từ máy khách để chỉ yêu cầu một phần tài nguyên

207 Đa trạng thái [WebDAV]

Một chỉ báo cho khách hàng rằng nhiều thao tác đã xảy ra và trạng thái của từng thao tác có thể được tìm thấy trong phần nội dung của phản hồi

208 Đã được báo cáo [WebDAV]

Cho phép máy khách nói với máy chủ rằng cùng một tài nguyên [có cùng ràng buộc] đã được đề cập trước đó. Nó không bao giờ xuất hiện dưới dạng mã phản hồi HTTP thực trong dòng trạng thái và chỉ xuất hiện trong nội dung

226 IM đã sử dụng

Máy chủ đã hoàn thành yêu cầu GET cho tài nguyên và phản hồi là biểu thị kết quả của một hoặc nhiều thao tác phiên bản được áp dụng cho phiên bản hiện tại

Mã trạng thái 3xx [Chuyển hướng]

Mã trạng thái

Sự mô tả

300 Nhiều lựa chọn

Yêu cầu có nhiều hơn một phản hồi có thể. Tác nhân người dùng hoặc người dùng nên chọn một trong số họ

301 Di chuyển vĩnh viễn

URL của tài nguyên được yêu cầu đã được thay đổi vĩnh viễn. URL mới được cung cấp bởi trường tiêu đề Location trong phản hồi. Phản hồi này có thể lưu vào bộ nhớ cache trừ khi có chỉ định khác

302 tìm thấy

URL của tài nguyên được yêu cầu đã được thay đổi tạm thời. URL mới được cung cấp bởi trường Location trong phản hồi. Phản hồi này chỉ có thể lưu vào bộ nhớ cache nếu được biểu thị bằng trường tiêu đề Cache-Control hoặc Expires

303 Xem Khác

Có thể tìm thấy phản hồi dưới một URI khác và NÊN được truy xuất bằng phương thức GET trên tài nguyên đó

304 Không được sửa đổi

Cho khách hàng biết rằng phản hồi chưa được sửa đổi, vì vậy khách hàng có thể tiếp tục sử dụng cùng một phiên bản phản hồi được lưu trong bộ nhớ cache

305 Sử dụng Proxy [Không dùng nữa]

Cho biết rằng phản hồi được yêu cầu phải được truy cập bằng proxy

306 [Không sử dụng]

Nó là một mã trạng thái dành riêng và không được sử dụng nữa

Chuyển hướng tạm thời 307

Cho biết ứng dụng khách nhận tài nguyên được yêu cầu tại một URI khác với cùng một phương thức đã được sử dụng trong yêu cầu trước đó. Nó tương tự như 302 Found với một ngoại lệ là sẽ sử dụng cùng một phương thức HTTP đã được sử dụng trong yêu cầu trước đó

Chuyển hướng vĩnh viễn 308 [thử nghiệm]

Cho biết rằng tài nguyên hiện được định vị vĩnh viễn tại một URI khác, được chỉ định bởi tiêu đề Location. Nó tương tự như

        @foreach[$serviceoverviews as $key => $serviceoverview]
            

        @endforeach
        
    
    
        
            #
            Service
            Package
            Service Type
            Date
            Price
            Days

        
    

    
                {{ ++$key }}
                {{ $serviceoverview->service_name }}
                {{ $serviceoverview->package_name }}
                {{ $serviceoverview->service_type }}
                {{ serviceoverview->created_at }}
                {{ $serviceoverview->price }}
                {{ $serviceoverview->days }}                
            
            
                {{ $serviceoverview->appends[\Request::all[]]->links[] }}
            
                 
    

1 với một ngoại lệ là sẽ sử dụng cùng một phương thức HTTP đã được sử dụng trong yêu cầu trước đó

Mã trạng thái 4xx [Lỗi máy khách]

Mã trạng thái

Sự mô tả

400 yêu cầu sai

Máy chủ không thể hiểu được yêu cầu do cú pháp sai. Khách hàng KHÔNG NÊN lặp lại yêu cầu mà không sửa đổi

401 trái phép

Cho biết rằng yêu cầu yêu cầu thông tin xác thực người dùng. Máy khách CÓ THỂ lặp lại yêu cầu với trường tiêu đề Ủy quyền phù hợp

Yêu cầu thanh toán 402 [Thử nghiệm]

Để dành mai sau dùng. Nó nhằm mục đích sử dụng trong các hệ thống thanh toán kỹ thuật số

403 cấm

yêu cầu trái phép. Khách hàng không có quyền truy cập vào nội dung. Không giống như 401, danh tính của khách hàng được máy chủ biết

404 không tìm thấy

Máy chủ không thể tìm thấy tài nguyên được yêu cầu

Phương pháp 405 không được phép

Phương thức HTTP yêu cầu được máy chủ biết nhưng đã bị vô hiệu hóa và không thể được sử dụng cho tài nguyên đó

406 Không được chấp nhận

Máy chủ không tìm thấy bất kỳ nội dung nào phù hợp với tiêu chí do tác nhân người dùng đưa ra trong tiêu đề Link0 được gửi trong yêu cầu

Yêu cầu xác thực proxy 407

Cho biết rằng trước tiên, máy khách phải tự xác thực bằng proxy

480 Thời gian yêu cầu hết giờ

Cho biết rằng máy chủ không nhận được yêu cầu hoàn chỉnh từ máy khách trong khoảng thời gian chờ được phân bổ của máy chủ

409 Xung đột

Không thể hoàn thành yêu cầu do xung đột với trạng thái hiện tại của tài nguyên

410

Tài nguyên được yêu cầu không còn khả dụng tại máy chủ

411 Độ dài yêu cầu

Máy chủ từ chối chấp nhận yêu cầu mà không có Nội dung- Độ dài được xác định. Máy khách CÓ THỂ lặp lại yêu cầu nếu nó thêm trường tiêu đề Link1 hợp lệ

412 Điều kiện tiên quyết không thành công

Máy khách đã chỉ ra các điều kiện tiên quyết trong tiêu đề của nó mà máy chủ không đáp ứng

413 Thực thể yêu cầu quá lớn

Thực thể yêu cầu lớn hơn giới hạn do máy chủ xác định

URI yêu cầu 414 quá dài

URI do máy khách yêu cầu dài hơn máy chủ có thể diễn giải

415 Loại phương tiện không được hỗ trợ

Loại phương tiện trong Link2 của yêu cầu không được máy chủ hỗ trợ

416 Phạm vi yêu cầu không thỏa đáng

Không thể đáp ứng phạm vi được chỉ định bởi trường tiêu đề Range trong yêu cầu

417 mong đợi thất bại

Kỳ vọng được chỉ định bởi trường tiêu đề yêu cầu Link4 không thể được đáp ứng bởi máy chủ

418 Tôi là một ấm trà [RFC 2324]

Nó được định nghĩa là trò đùa lool của April và dự kiến ​​sẽ không được triển khai bởi các máy chủ HTTP thực tế. [RFC 2324]

420 Nâng cao sự bình tĩnh của bạn [Twitter]

Được API Xu hướng và Tìm kiếm Twitter trả về khi ứng dụng khách bị giới hạn tốc độ

422 Thực thể không thể xử lý [WebDAV]

Máy chủ hiểu loại nội dung và cú pháp của thực thể yêu cầu, nhưng máy chủ vẫn không thể xử lý yêu cầu vì một số lý do

423 Đã khóa [WebDAV]

Tài nguyên đang được truy cập đã bị khóa

424 Phụ thuộc không thành công [WebDAV]

Yêu cầu không thành công do yêu cầu trước đó không thành công

425 Quá sớm [WebDAV]

Cho biết rằng máy chủ không muốn mạo hiểm xử lý một yêu cầu có thể được phát lại

Yêu cầu nâng cấp 426

Máy chủ từ chối thực hiện yêu cầu. Máy chủ sẽ xử lý yêu cầu sau khi máy khách nâng cấp lên một giao thức khác

428 Yêu cầu điều kiện tiên quyết

Máy chủ gốc yêu cầu yêu cầu phải có điều kiện

429 Yêu cầu quá nhiều

Người dùng đã gửi quá nhiều yêu cầu trong một khoảng thời gian nhất định [“giới hạn tốc độ”]

431 Trường tiêu đề yêu cầu quá lớn

Máy chủ không muốn xử lý yêu cầu vì các trường tiêu đề của nó quá lớn

444 Không có phản hồi [Nginx]

Máy chủ Nginx không trả lại thông tin nào cho máy khách và đóng kết nối

449 Thử lại với [Microsoft]

Yêu cầu phải được thử lại sau khi thực hiện hành động thích hợp

450 Bị chặn bởi Windows Parental Controls [Microsoft]

Windows Parental Controls được bật và đang chặn quyền truy cập vào trang web đã cho

451 Không có sẵn vì lý do pháp lý

Tác nhân người dùng đã yêu cầu một tài nguyên không thể được cung cấp một cách hợp pháp

499 Client Closed Request [Nginx]

Kết nối bị đóng bởi máy khách trong khi máy chủ HTTP đang xử lý yêu cầu của nó, khiến máy chủ không thể gửi lại tiêu đề HTTP

Mã trạng thái 5xx [Lỗi máy chủ]

Mã trạng thái

Sự mô tả

500 Lỗi máy chủ nội bộ

Máy chủ gặp phải tình trạng không mong muốn khiến nó không thể thực hiện yêu cầu

501 Không thực hiện

Phương thức HTTP không được máy chủ hỗ trợ và không thể xử lý

502 Cổng Xấu

Máy chủ nhận được phản hồi không hợp lệ khi đang hoạt động như một cổng nhận phản hồi cần thiết để xử lý yêu cầu

Lỗi 503: Dịch vụ không khả dụng

Máy chủ chưa sẵn sàng để xử lý yêu cầu

Hết thời gian chờ cổng 504

Máy chủ đang hoạt động như một cổng và không thể nhận được phản hồi kịp thời cho một yêu cầu

Phiên bản HTTP 505 không được hỗ trợ [Thử nghiệm]

Phiên bản HTTP được sử dụng trong yêu cầu không được máy chủ hỗ trợ

Biến thể 506 cũng thương lượng [Thử nghiệm]

Cho biết máy chủ có lỗi cấu hình bên trong. tài nguyên biến thể đã chọn được định cấu hình để tự tham gia vào quá trình thương lượng nội dung minh bạch và do đó không phải là điểm cuối thích hợp trong quá trình thương lượng

507 Dung lượng lưu trữ không đủ [WebDAV]

Không thể thực hiện phương pháp này trên tài nguyên vì máy chủ không thể lưu trữ biểu diễn cần thiết để hoàn thành thành công yêu cầu

Đã phát hiện vòng lặp 508 [WebDAV]

Máy chủ đã phát hiện một vòng lặp vô hạn trong khi xử lý yêu cầu

510 Không mở rộng

Cần có các phần mở rộng khác cho yêu cầu để máy chủ thực hiện yêu cầu đó

Yêu cầu xác thực mạng 511

Cho biết rằng máy khách cần xác thực để có quyền truy cập mạng

6. Mã trạng thái HTTP cụ thể của REST

200 [được]

Nó chỉ ra rằng API REST đã thực hiện thành công bất kỳ hành động nào mà khách hàng yêu cầu và không có mã cụ thể nào nữa trong chuỗi 2xx là phù hợp

Không giống như mã trạng thái 204, phản hồi 200 phải bao gồm nội dung phản hồi. Thông tin được trả về cùng với phản hồi phụ thuộc vào phương thức được sử dụng trong yêu cầu, ví dụ:

• NHẬN một thực thể tương ứng với tài nguyên được yêu cầu được gửi trong phản hồi;
• HEAD các trường tiêu đề thực thể tương ứng với tài nguyên được yêu cầu được gửi trong phản hồi mà không có bất kỳ nội dung thư nào;
• ĐĂNG một thực thể mô tả hoặc chứa kết quả của hành động;
• THEO DÕI thực thể chứa thông báo yêu cầu mà máy chủ cuối nhận được

201 [Đã tạo]

API REST phản hồi với mã trạng thái 201 bất cứ khi nào tài nguyên được tạo bên trong bộ sưu tập. Cũng có thể đôi khi một tài nguyên mới được tạo do một số hành động của bộ điều khiển, trong trường hợp đó 201 cũng sẽ là một phản hồi thích hợp

Tài nguyên mới được tạo có thể được tham chiếu bởi [các] URI được trả về trong thực thể của phản hồi, với URI cụ thể nhất cho tài nguyên được cung cấp bởi trường tiêu đề Vị trí

Máy chủ gốc PHẢI tạo tài nguyên trước khi trả lại mã trạng thái 201. Nếu hành động không thể được thực hiện ngay lập tức, thay vào đó, máy chủ NÊN phản hồi bằng phản hồi 202 [Được chấp nhận]

202 [Đã chấp nhận]

Phản hồi 202 thường được sử dụng cho các hành động mất nhiều thời gian để xử lý. Nó chỉ ra rằng yêu cầu đã được chấp nhận để xử lý, nhưng quá trình xử lý chưa được hoàn thành. Yêu cầu cuối cùng có thể hoặc không thể được thực hiện hoặc thậm chí có thể không được phép khi quá trình xử lý diễn ra

Mục đích của nó là cho phép máy chủ chấp nhận yêu cầu đối với một số quy trình khác [có thể là quy trình định hướng theo đợt chỉ chạy một lần mỗi ngày] mà không yêu cầu kết nối của tác nhân người dùng với máy chủ vẫn tiếp tục cho đến khi quá trình hoàn tất

Thực thể được trả về với phản hồi này NÊN bao gồm chỉ báo về trạng thái hiện tại của yêu cầu và con trỏ tới trình theo dõi trạng thái [vị trí hàng đợi công việc] hoặc một số ước tính về thời điểm người dùng có thể mong đợi yêu cầu được thực hiện

204 [Không có nội dung]

Mã trạng thái 204 thường được gửi đi để phản hồi yêu cầu Link5, Link6 hoặc Link7 khi API REST từ chối gửi lại bất kỳ thông báo trạng thái hoặc đại diện nào trong nội dung của thông báo phản hồi

API cũng có thể gửi 204 cùng với yêu cầu GET để cho biết rằng tài nguyên được yêu cầu tồn tại, nhưng không có đại diện trạng thái để đưa vào phần thân

Nếu máy khách là tác nhân người dùng, nó KHÔNG NÊN thay đổi chế độ xem tài liệu của nó so với chế độ xem khiến yêu cầu được gửi. Phản hồi này chủ yếu nhằm mục đích cho phép đầu vào cho các hành động diễn ra mà không gây ra thay đổi đối với chế độ xem tài liệu đang hoạt động của tác nhân người dùng. Tuy nhiên, bất kỳ siêu thông tin mới hoặc cập nhật nào NÊN được áp dụng cho tài liệu hiện ở chế độ xem động của tác nhân người dùng

Phản hồi 204 KHÔNG ĐƯỢC bao gồm nội dung thư và do đó luôn được kết thúc bằng dòng trống đầu tiên sau các trường tiêu đề

301 [Đã di chuyển vĩnh viễn]

Mã trạng thái 301 chỉ ra rằng mô hình tài nguyên của API REST đã được thiết kế lại đáng kể và URI vĩnh viễn mới đã được gán cho tài nguyên được yêu cầu của khách hàng. API REST phải chỉ định URI mới trong tiêu đề Vị trí của phản hồi và tất cả các yêu cầu trong tương lai phải được chuyển hướng đến URI đã cho

Bạn sẽ hầu như không sử dụng mã phản hồi này trong API của mình vì bạn luôn có thể sử dụng phiên bản API cho API mới trong khi vẫn giữ lại phiên bản cũ

302 [Đã tìm thấy]

Mã trạng thái phản hồi HTTP 302 Đã tìm thấy là một cách phổ biến để thực hiện chuyển hướng URL. Phản hồi HTTP với mã trạng thái này sẽ cung cấp thêm một URL trong trường tiêu đề Vị trí. Tác nhân người dùng [e. g. , một trình duyệt web] được mời bởi một phản hồi với mã này để tạo giây. Mặt khác, giống hệt nhau, hãy yêu cầu URL mới được chỉ định trong trường vị trí

Nhiều trình duyệt web đã triển khai mã này theo cách vi phạm tiêu chuẩn này, thay đổi loại yêu cầu của yêu cầu mới thành GET, bất kể loại được sử dụng trong yêu cầu ban đầu [e. g. , BƯU KIỆN]. RFC 1945 và RFC 2068 chỉ định rằng máy khách không được phép thay đổi phương thức theo yêu cầu được chuyển hướng. Mã trạng thái 303 và 307 đã được thêm vào cho các máy chủ muốn làm rõ ràng loại phản ứng nào được mong đợi từ máy khách

303 [Xem Khác]

Phản hồi 303 cho biết rằng tài nguyên bộ điều khiển đã hoàn thành công việc của nó, nhưng thay vì gửi nội dung phản hồi có khả năng không mong muốn, nó sẽ gửi cho khách hàng URI của tài nguyên phản hồi. Phản hồi có thể là URI của thông báo trạng thái tạm thời hoặc URI của một số tài nguyên đã tồn tại, lâu dài hơn

Nói chung, mã trạng thái 303 cho phép API REST gửi tham chiếu đến tài nguyên mà không buộc khách hàng tải xuống trạng thái của nó. Thay vào đó, khách hàng có thể gửi yêu cầu GET tới giá trị của tiêu đề Vị trí

Phản hồi 303 KHÔNG ĐƯỢC lưu vào bộ đệm, nhưng phản hồi cho yêu cầu thứ hai [được chuyển hướng] có thể được lưu vào bộ đệm

304 [Không sửa đổi]

Mã trạng thái này tương tự như 204 [“Không có nội dung”] ở chỗ nội dung phản hồi phải trống. Sự khác biệt quan trọng là 204 được sử dụng khi không có gì để gửi trong nội dung, trong khi 304 được sử dụng khi tài nguyên chưa được sửa đổi kể từ phiên bản được chỉ định bởi các tiêu đề yêu cầu If-Modified-Since hoặc If-None-Match

Trong trường hợp này, không cần truyền lại tài nguyên vì máy khách vẫn có bản sao đã tải xuống trước đó

Sử dụng điều này giúp tiết kiệm băng thông và xử lý lại trên cả máy chủ và máy khách, vì chỉ dữ liệu tiêu đề phải được gửi và nhận so với toàn bộ trang được máy chủ xử lý lại, sau đó được gửi lại bằng cách sử dụng nhiều băng thông hơn của máy chủ và máy khách

307 [Chuyển hướng tạm thời]

Phản hồi 307 cho biết API REST sẽ không xử lý yêu cầu của khách hàng. Thay vào đó, khách hàng nên gửi lại yêu cầu tới URI được chỉ định bởi tiêu đề Vị trí của thông báo phản hồi. Tuy nhiên, các yêu cầu trong tương lai vẫn nên sử dụng URI gốc

API REST có thể sử dụng mã trạng thái này để gán URI tạm thời cho tài nguyên được yêu cầu của khách hàng. Ví dụ: phản hồi 307 có thể được sử dụng để chuyển yêu cầu của máy khách sang máy chủ khác

URI tạm thời NÊN được cung cấp bởi trường Vị trí trong phản hồi. Trừ khi phương thức yêu cầu là HEAD, thực thể của phản hồi NÊN chứa một ghi chú siêu văn bản ngắn có siêu liên kết đến [các] URI mới. Nếu mã trạng thái 307 được nhận để phản hồi một yêu cầu không phải là Link8 hoặc Link9, tác nhân người dùng KHÔNG ĐƯỢC tự động chuyển hướng yêu cầu trừ khi người dùng có thể xác nhận, vì điều này có thể thay đổi các điều kiện theo đó yêu cầu được đưa ra

400 [Yêu cầu không hợp lệ]

400 là trạng thái lỗi chung phía máy khách, được sử dụng khi không có mã lỗi 4xx nào khác phù hợp. Các lỗi có thể giống như cú pháp yêu cầu không đúng định dạng, tham số thông báo yêu cầu không hợp lệ hoặc định tuyến yêu cầu lừa đảo, v.v.

Khách hàng KHÔNG NÊN lặp lại yêu cầu mà không sửa đổi

401 [Trái phép]

Phản hồi lỗi 401 cho biết rằng máy khách đã cố gắng vận hành trên tài nguyên được bảo vệ mà không cung cấp quyền thích hợp. Nó có thể đã cung cấp thông tin đăng nhập sai hoặc không có gì cả. Phản hồi phải bao gồm trường tiêu đề WWW-Xác thực chứa thách thức áp dụng cho tài nguyên được yêu cầu

Máy khách CÓ THỂ lặp lại yêu cầu với trường tiêu đề Ủy quyền phù hợp. Nếu yêu cầu đã bao gồm thông tin đăng nhập Ủy quyền, thì phản hồi 401 cho biết rằng ủy quyền đã bị từ chối đối với những thông tin đăng nhập đó. Nếu phản hồi 401 chứa cùng một thách thức như phản hồi trước đó và tác nhân người dùng đã thử xác thực ít nhất một lần, thì người dùng NÊN được trình bày thực thể đã được cung cấp trong phản hồi, vì thực thể đó có thể bao gồm thông tin chẩn đoán có liên quan

403 [Cấm]

Phản hồi lỗi 403 cho biết rằng yêu cầu của khách hàng được tạo chính xác, nhưng API REST từ chối thực hiện yêu cầu đó, tôi. e. , người dùng không có quyền cần thiết đối với tài nguyên. Phản hồi 403 không phải là trường hợp không đủ thông tin đăng nhập của khách hàng;

Xác thực sẽ không giúp được gì và KHÔNG NÊN lặp lại yêu cầu. Không giống như phản hồi 401 Trái phép, việc xác thực sẽ không tạo ra sự khác biệt nào

404 không tìm thấy]

Mã trạng thái lỗi 404 cho biết rằng API REST không thể ánh xạ URI của máy khách tới một tài nguyên nhưng có thể khả dụng trong tương lai. Các yêu cầu tiếp theo của khách hàng được cho phép

Không có dấu hiệu nào cho biết tình trạng này là tạm thời hay vĩnh viễn. Mã trạng thái 410 [Đã biến mất] NÊN được sử dụng nếu máy chủ biết, thông qua một số cơ chế có thể định cấu hình nội bộ, rằng tài nguyên cũ vĩnh viễn không khả dụng và không có địa chỉ chuyển tiếp. Mã trạng thái này thường được sử dụng khi máy chủ không muốn tiết lộ chính xác lý do tại sao yêu cầu bị từ chối hoặc khi không có phản hồi nào khác được áp dụng

405 [Phương pháp không được phép]

API phản hồi với lỗi 405 để cho biết rằng khách hàng đã cố sử dụng phương thức HTTP mà tài nguyên không cho phép. Chẳng hạn, tài nguyên chỉ đọc chỉ có thể hỗ trợ GET và HEAD, trong khi tài nguyên bộ điều khiển có thể cho phép GET và POST, nhưng không hỗ trợ PUT hoặc DELETE

Phản hồi 405 phải bao gồm tiêu đề Cho phép, liệt kê các phương thức HTTP mà tài nguyên hỗ trợ. Ví dụ

Allow: GET, POST

406 [Không được chấp nhận]

Phản hồi lỗi 406 cho biết rằng API không thể tạo bất kỳ loại phương tiện ưa thích nào của ứng dụng khách, như được biểu thị bằng tiêu đề Yêu cầu chấp nhận. Ví dụ: yêu cầu của khách hàng đối với dữ liệu được định dạng là Range0 sẽ nhận được phản hồi 406 nếu API chỉ sẵn sàng định dạng dữ liệu là Range1

Nếu phản hồi có thể không được chấp nhận, tác nhân người dùng NÊN tạm thời ngừng nhận thêm dữ liệu và truy vấn người dùng để đưa ra quyết định về các hành động tiếp theo

412 [Điều kiện tiên quyết không thành công]

Phản hồi lỗi 412 cho biết rằng ứng dụng khách đã chỉ định một hoặc nhiều điều kiện tiên quyết trong tiêu đề yêu cầu của nó, thông báo hiệu quả cho API REST để thực hiện yêu cầu của nó chỉ khi một số điều kiện nhất định được đáp ứng. Phản hồi 412 cho biết rằng các điều kiện đó không được đáp ứng, do đó, thay vì thực hiện yêu cầu, API sẽ gửi mã trạng thái này

415 [Loại phương tiện không được hỗ trợ]

Phản hồi lỗi 415 cho biết rằng API không thể xử lý loại phương tiện do khách hàng cung cấp, như được chỉ ra bởi tiêu đề yêu cầu Loại nội dung. Ví dụ: yêu cầu của khách hàng bao gồm dữ liệu được định dạng là Range0 sẽ nhận được phản hồi 415 nếu API chỉ sẵn sàng xử lý dữ liệu được định dạng là Range1

Ví dụ: máy khách tải lên hình ảnh dưới dạng image/svg+xml, nhưng máy chủ yêu cầu hình ảnh đó sử dụng định dạng khác

500 [Lỗi máy chủ nội bộ]

500 là phản hồi lỗi API REST chung. Hầu hết các khung web tự động phản hồi với mã trạng thái phản hồi này bất cứ khi nào chúng thực thi một số mã xử lý yêu cầu làm phát sinh ngoại lệ

Lỗi 500 không bao giờ là lỗi của khách hàng và do đó, thật hợp lý khi khách hàng thử lại cùng một yêu cầu đã kích hoạt phản hồi này và hy vọng nhận được phản hồi khác

Phản hồi API là thông báo lỗi chung, được đưa ra khi gặp phải tình trạng không mong muốn và không có thông báo cụ thể nào phù hợp

501 [Chưa triển khai]

Máy chủ không nhận ra phương thức yêu cầu hoặc không thể thực hiện yêu cầu. Thông thường, điều này ngụ ý tính khả dụng trong tương lai [e. g. , một tính năng mới của API dịch vụ web]