Cơ sở hạ tầng tin cậy
API REST phù hợp và dễ đọc với con người. Đó là tài liệu tự.
GET wp-json/wp/v2/postslà khá rõ ràng những gì nó làm. Đó GETlà một số bài viết.
Bạn có một không gian tên : wp, phiên bản: v2và bộ sưu tập đối tượngposts
Bạn có thể đoán những gì: GET wp-json/wp/v2/posts/5không? Làm thế nào về: GET wp-json/wp/v2/posts/5/comments
Làm thế nào về:GET wp-json/shop/v2/orders/345/lines/11/price
Một nhà phát triển có thể dễ dàng đoán bằng cách nhìn vào đó, nó sẽ nhận được giá của 11đơn hàng 345ngay cả khi không đọc tài liệu. Nhà phát triển thậm chí có thể dễ dàng biết rằng nó đến từ shopPlugin vì nó được đặt tên.
Thế POST /wp-json/v2/posts title=New Blog Post
cònPUT /wp-json/v2/posts title=New Title
Điều đó cũng khá rõ ràng. Nó làm cho một bài viết mới. Nhân tiện, nó trả về ID của bài viết mới. Đây không phải là về AJAX HOẶC API REST. AJAX đơn giản là một công nghệ truy cập API REST. Trong khi đó, trước đây, bạn sẽ phải đưa ra một loạt các tên hàm ajax trừu tượng như :
get_price_for_lineitem( $order, $line ). Điều đó sẽ trả về chỉ là một số hay một đối tượng JSON? Tôi không chắc chắn, tài liệu ở đâu. Oh ... là cuộc gọi ajax get_order_line_pricehay get_lineitem_price.
Nhà phát triển không phải đưa ra các quyết định này, vì wp-jsonapi hiện tại cung cấp một mô hình cơ sở tốt để tuân theo khi tạo các điểm cuối của riêng bạn. Chắc chắn, một nhà phát triển plugin hoặc api có thể phá vỡ các quy tắc này, nhưng nói chung, việc tuân theo một tiêu chuẩn đã được đặt ra dễ dàng hơn và hầu hết các nhà phát triển sẽ tuân theo một mẫu đã được thiết lập (xem cách các mẫu jQuery phổ biến hiện nay).
TÓM TẮT mà không mất tập trung
Tôi có quan tâm đến cách làm POST /wp-json/mysite/v1/widgets title=Foobarviệc không? Không. Tôi chỉ muốn tạo một cái mới Widgetvà tôi muốn đổi lại ID. Tôi muốn làm điều đó từ một hình thức ở mặt trước của tôi mà không làm mới trang. Nếu tôi yêu cầu URL, tôi không quan tâm nếu đó là PHP, C #, ASP.NET hoặc bất kỳ công nghệ nào khác. Tôi chỉ muốn tạo một Widget mới.
API REST tách riêng phần phụ trợ từ phía trước. Về mặt kỹ thuật, nếu API của bạn đủ tốt, bạn có thể thay đổi toàn bộ ngăn xếp phụ trợ của mình. Miễn là bạn duy trì cấu trúc API REST giống nhau, mọi thứ phụ thuộc vào API sẽ không bị ảnh hưởng.
Nếu API REST của bạn đủ đơn giản và đủ nhất quán, sử dụng một danh từ như Widgetslà một bộ sưu tập các đối tượng và danh từ / định danh muốn Widget/2chỉ một thực thể duy nhất, thì thật sự đơn giản để viết API đó trong một công nghệ khác rất nhiều vì nó ít nhiều là cơ sở dữ liệu cơ bản mã.
Sử dụng các động từ Yêu cầu HTTP tiêu chuẩn.
API REST tận dụng cốt lõi của cách thức hoạt động của web và các ĐỘNG TỪ (đọc: hành động) mà bạn sử dụng bản đồ cho các hàm CRUD dữ liệu tiêu chuẩn.
CREATE : POST
READ : GET
UPDATE : PUT/PATCH
DELETE : DELETE
Có nhiều động từ HTTP hơn, nhưng đó là những điều cơ bản. Mỗi yêu cầu qua internet sử dụng các động từ này. API REST nằm ngay trên mô hình mà web được xây dựng theo yêu cầu. Không cần bất kỳ lớp truyền thông hoặc mô hình trừu tượng ở giữa. Đó chỉ là một yêu cầu http tiêu chuẩn cho một URL và nó trả về một phản hồi. Bạn không thể đơn giản hơn thế.
Về cơ bản, nó làm cho nhà phát triển nhận thức rõ hơn về các loại hạt và bu lông về cách thức hoạt động của web và khi bạn hiểu rõ hơn về cách thức hoạt động của các giao thức cơ bản, cuối cùng bạn sẽ tạo ra một sản phẩm hiệu quả hơn.