Điều gì để gọi API HTTP không phải là RESTful? [đóng cửa]

Bạn sẽ gọi API dựa trên HTTP là gì, sử dụng URI để đặt tên cho tài nguyên và động từ HTTP (PUT, POST, DELETE, GET ...) để thao túng các tài nguyên đó?

Theo khiếu nại của Roy Fielding, đó không phải là REST, vì không có hypermedia.

Trong nội bộ, trong nhóm của tôi, mọi người gọi nó là "API REST". Tôi gọi nó là "giống như REST" nhưng nó không được mô tả và ý nghĩa của nó là mờ nhạt. Tôi khá bối rối về điều đó, vì có sự bất đồng lớn về REST. Tôi không muốn tham gia vào các cuộc chiến lửa, nhưng chỉ sử dụng các thuật ngữ chính xác.

Gọi nó là API HTTP .

Nó tuân thủ các tiêu chuẩn HTTP và không có bất kỳ thứ gì khác được xếp chồng lên trên (ví dụ SOAP).

Các tiêu chuẩn HTTP xác định tài nguyên, động từ, tiêu đề, đàm phán nội dung, v.v.

REST (Chuyển giao trạng thái REpresentational) là một kiến ​​trúc với các yêu cầu có thể tuân theo các tiêu chuẩn HTTP hiện có, nhưng HTTP tự hoạt động hoàn toàn.

Theo kinh nghiệm của tôi, 90% "API HTTP REST" nên tự gọi mình là "chỉ" một API HTTP.

Đừng xấu hổ khi rời khỏi nhãn REST. Như với microservice và cơ sở dữ liệu không liên quan, bạn không cần phải có API RESTful để làm mát. Roy bắt đầu tạo ra kiến ​​trúc ứng dụng được nối mạng lâu nhất, tương thích ngược nhất mà anh có thể. Anh ấy đã làm một công việc tốt. Nhưng không phải mọi thứ đều cần hơn 40 năm tương thích.

Mô hình trưởng thành của Richardson diễn ra như thế này

0. POST ở khắp mọi nơi. Một điểm cuối duy nhất. (XÀ BÔNG TẮM)
1. POST ở khắp mọi nơi. Nhiều điểm cuối. (tài nguyên)
2. ĐỘNG TỪ HTTP. Nhiều điểm cuối.
3. Giống như 2 và trả về liên kết đến tài nguyên. (RESTful)

Vì vậy, theo mô hình tôi sẽ gọi nó là một dịch vụ web phù hợp với richardson cấp 2 hoặc một cái gì đó dọc theo các dòng đó.

http://martinfowler.com/articles/richardsonMaturityModel.html

Hypermedia chưa bao giờ thực sự phổ biến với các API giống như REST - đến mức khi một API thực sự thực hiện điều hướng hypermedia, thuật ngữ RESTful đơn giản là không đủ để phân biệt với các API web "RESTful" khác. REST đã trở thành một thuật ngữ bắt kịp hoặc bất kỳ API web dựa trên tài nguyên nào và các tên mới như Hypermedia API  đã được đặt ra để tập trung vào khái niệm hypermedia.

Tôi thực sự không muốn ủng hộ việc sử dụng các thuật ngữ không chính xác, nhưng tôi nghĩ rằng cách giải thích hiện đại chung của REST chỉ đơn giản là sử dụng các URL và động từ HTTP thống nhất cho hầu hết mọi người. Điều đó không đúng, nhưng bất cứ ai biết định nghĩa Fieldings, cũng nên biết rằng nhiều người khác không biết. Mặt khác, bất cứ ai biết REST chỉ bằng cách quan sát cách API "RESTful" hiện tại được triển khai, sẽ không biết bạn đang nói về điều gì khi bạn đề cập đến các ràng buộc REST ít được biết đến như HATEOAS hoặc mã theo yêu cầu. Fielding có thể không thích nó, nhưng tôi nghĩ rằng đã muộn để quay lại định nghĩa ban đầu *. Và hãy trung thực: Nếu bạn nghe ai đó nói về API REST của anh ấy lần đầu tiên, bạn ngay lập tức cho rằng nó không bao gồm hypermedia, phải không?

Nhấn mạnh vào định nghĩa chính xác của RESTful thường chỉ tạo thêm sự nhầm lẫn. Như với nhiều thuật ngữ đã thay đổi ý nghĩa của chúng theo thời gian hoặc rằng quần chúng đơn giản chấp nhận sai, tôi đánh giá cao nếu ai đó biết định nghĩa ban đầu nhưng tôi sẽ không sửa bất cứ ai đang sử dụng cách hiểu hiện đại hơn về REST.

_{* và cũng đến muộn để thiết lập các thuật ngữ mới cho API không phải hypermedia giống như REST, cho vấn đề đó. Làm thế nào chúng ta nên gọi họ? ... PHỤC HỒI ?}

Đó là giao diện CRUD (Tạo, Đọc, Cập nhật, Xóa) qua HTTP.

Tôi không thể nghĩ ra bất kỳ cơ quan chức năng nào ủng hộ khẳng định này, vì vậy tôi hy vọng bạn nhận được nhiều câu trả lời hơn và tốt hơn.

Bạn có thể gọi nó là bất cứ điều gì bạn thích, mọi người có xu hướng (gần như tôn giáo) bám vào bất kỳ phần nào của 'thông số' mà bạn không theo dõi và sử dụng nó như một điểm phản đối rất bất lợi cho sự phát triển. Nhưng điều đó nói rằng, thực tế đơn giản là có (gần) không có dịch vụ nào tồn tại thực hiện REST thực sự cho API của họ phục vụ.

Trong nhóm của chúng tôi, chúng tôi đã đặt tên cho chúng tôi Stateless APIkhi nó đang được phát triển vì chúng tôi có API SOAP Nhà nước và Chức năng mà chúng tôi đã thay thế (chính API kế thừa không bao giờ có tên đồng ý và có ý nghĩa vì vậy chúng tôi đã không bị cuốn theo tên ).

Bây giờ dự án này chỉ có một API, nó được gọi đơn giản the <project> API. Cuối cùng khi chúng ta thay thế nó, API mới sẽ được gọi đơn giản là the new <project> API.

Đặt cho nó bất kỳ tên nội bộ mô tả và lạ mắt nào là gần như vô nghĩa trừ khi bạn có rất nhiều API mà bạn cần phân biệt cái này với phần còn lại (trong trường hợp đó bạn có lẽ nên đổi tên tất cả các API khác).

Bạn có thể gọi nó là API Web . Đây là một thuật ngữ rất rộng nhưng nó có thể tránh được sự hiểu biết về ý nghĩa của các định nghĩa loại API khác. Thuật ngữ này ít kỹ thuật và chính xác hơn so với các lựa chọn thay thế như API HTTP , nhưng đó có thể là một lợi thế khi nói chuyện với những người không có kỹ thuật.

Thuật ngữ này cũng được sử dụng bởi Leonard Richardson (người đã xác định Mô hình trưởng thành của Richardson đã được đề cập đến một câu trả lời khác - một phép đo được chấp nhận tốt cho mức độ gần gũi của API với kiến ​​trúc REST). Đó là những gì bạn nhận được nếu bạn bỏ phần "RESTful" của " API Web RESTful ".