Nhu cầu của Odata khi tôi có JSON là gì?

Tôi đang cố gắng để hiểu quan điểm của Odata và khi nào nó sẽ có ý nghĩa. Ngay bây giờ cách tôi làm việc là tôi sử dụng bộ điều khiển ASP.NET và MVC / WebApi để tuần tự hóa / giải tuần tự hóa các đối tượng thành JSON và để javascript làm điều gì đó với nó.

Từ những gì tôi có thể nói lợi ích của OData là có thể truy vấn trực tiếp từ URL ... Nhưng vì tôi đang viết mã máy khách và mã máy chủ nên không cần điều đó.

Có ai từng phân tích kết quả của một truy vấn ODaya trong javascript không ??

Có lẽ OData liên quan nhiều hơn đến việc cung cấp điểm cuối chung cho TẤT CẢ khách hàng để nhận thông tin chi tiết từ truy vấn mà JSON không cung cấp? Vì vậy, nếu tôi là một nhà cung cấp dữ liệu thì tôi cho rằng đó là odata để làm gì?

Giúp tôi hiểu mục đích và việc sử dụng REST / JSON / ODATA.

JSON chỉ là một định dạng trao đổi dữ liệu dựa trên JavaScript.

REST là một kiểu kiến ​​trúc trong khi OData là một triển khai cụ thể của REST được thiết kế để tạo và tiêu thụ dữ liệu, hỗ trợ hai định dạng, AtomPub và JSON.

Vì vậy, sự khác biệt giữa JSON với REST và OData đơn giản là các tùy chọn trong OData để thao tác dữ liệu, ví dụ: nếu chúng tôi truy vấn dữ liệu bằng giao thức OData, chúng tôi có thể chỉ định các tùy chọn bên dưới trong URI,

• $ đặt hàng
• $ hàng đầu
• $ bỏ qua
• $ bộ lọc
• định dạng $
• $ chọn

Chúng tôi có thể thực hiện phép chiếu, liên kết các tài nguyên, v.v. và tất cả các tùy chọn này đều có sẵn. Bây giờ hãy tưởng tượng nếu chúng ta phải cung cấp tất cả các tính năng này trong dịch vụ REST của chính mình thì chúng ta sẽ phải,

• Thực hiện tất cả chúng
• Tạo quy ước / từ khóa riêng của chúng tôi cho các hoạt động khác nhau

Nó không chỉ nhiều công việc mà còn dẫn đến sự không nhất quán và tạo ra một đường cong học tập cho người tiêu dùng dữ liệu của chúng tôi.

Ký hiệu đối tượng JSON hoặc JavaScript chỉ là một định dạng hoặc tiêu chuẩn cho dữ liệu. Đây là định dạng được thỏa thuận để truyền một cái gì đó như tên đăng nhập HOẶC thứ gì đó cần được sử dụng bởi Dịch vụ REST.

Xem phần này: http://en.wikipedia.org/wiki/JSON

Mặc dù ban đầu có nguồn gốc từ ngôn ngữ kịch bản JavaScript, JSON là định dạng dữ liệu độc lập với ngôn ngữ và mã để phân tích cú pháp và tạo dữ liệu JSON có sẵn trong nhiều ngôn ngữ lập trình.

Đây không phải là một phần của bất kỳ ngôn ngữ lập trình cụ thể nào, vì vậy các hệ thống khác nhau có thể chuyển dữ liệu khá dễ dàng, nếu họ biết họ đang sử dụng JSON.

Đối với REST, nó chỉ đơn giản là một kiểu kiến ​​trúc được sử dụng cho các dịch vụ web.

Xem phần này: http://en.wikipedia.org/wiki/Repftimeatic_state_transfer

Một cách để nghĩ về điều này, là nếu bạn muốn viết một dịch vụ web mà nhiều máy tính khác nhau có thể nói chuyện .. và trao đổi thông tin. Bạn có thể viết dịch vụ web của mình để chấp nhận dữ liệu qua URL

 http://www.myservice.com/specialRESTService?name=punkouter

Phản hồi có thể là một đối tượng JSON báo hiệu dữ liệu của bạn đã được nhận.

{
    "name": "punkouter",
    "status": "service downloaded your data",
}

Tôi chưa bao giờ nghe nói về OData, vì vậy tôi đã googled nó:

OData được xây dựng trên giao thức AtomPub và JSON trong đó cấu trúc Atom là đường bao chứa dữ liệu được trả về từ mỗi yêu cầu OData. Một yêu cầu OData sử dụng mô hình REST cho tất cả các yêu cầu. Mỗi lệnh REST là một yêu cầu POST, GET, PUT, PATCH hoặc DELETE (ánh xạ tới CRUD) trong đó các chi tiết cụ thể của lệnh nằm trong url.

NHẬN: Nhận một bộ sưu tập các thực thể (dưới dạng tài liệu nguồn cấp dữ liệu) hoặc một thực thể duy nhất (dưới dạng tài liệu nhập).

POST: Tạo một thực thể mới từ một tài liệu nhập cảnh.

PUT: Cập nhật một thực thể hiện có với một tài liệu nhập cảnh.

VĂN BẢN: Cập nhật một thực thể hiện có với một tài liệu nhập một phần.

XÓA: Xóa một thực thể.

Âm thanh như OData là thứ gì đó được viết để tăng thêm kiến ​​trúc theo phong cách REST của vanilla .. Nhưng có vẻ như nó có thể cung cấp cho bạn một số thứ được thêm vào để thay thế, thay vì phải viết những thứ từ đầu trong C # hoặc bất kỳ ngôn ngữ nào bạn đang sử dụng.

Nếu bạn làm việc đang thúc đẩy bạn sử dụng OData, bạn vẫn sẽ sử dụng JSON..nhưng trong khuôn khổ / tiêu chuẩn OData được viết bởi Microsoft et al.

Có ai từng phân tích kết quả của truy vấn OData (sic) trong javascript không ??

Vâng, vì (có vẻ như) nó đang sử dụng JSON. Việc sử dụng JS là hoàn toàn tự nhiên.

Có lẽ OData liên quan nhiều hơn đến việc cung cấp điểm cuối chung cho TẤT CẢ khách hàng để nhận thông tin chi tiết từ truy vấn mà JSON không cung cấp? Vì vậy, nếu tôi là một nhà cung cấp dữ liệu thì tôi cho rằng đó là những gì Odata dành cho?

Odata sẽ cung cấp dịch vụ REST .. nhưng với một số dịch vụ tiêu chuẩn được thêm vào trên điểm cuối của dịch vụ REST "chung" đơn giản .. khách hàng không quan tâm nếu bạn đang sử dụng OData, hoặc sử dụng dịch vụ C # của riêng bạn .. miễn là vì các câu trả lời theo định dạng đã được thống nhất (như JSON). Tuy nhiên, đối với công việc của bạn, có thể họ muốn sử dụng OData vì nó cung cấp rất nhiều tính năng 'ngoài luồng' ..

Đối với câu hỏi "tại sao", có một định nghĩa thực sự tốt trong cuốn sách API API RESTful - về cơ bản OData thực hiện một mẫu bộ sưu tập, trong đó bộ sưu tập là một tài nguyên cung cấp danh sách các tài nguyên thông qua các liên kết.

OData là triển khai cụ thể của dịch vụ RESTful với một tiêu chuẩn cho giao diện. Ưu điểm là khi bạn trưng ra API sản phẩm của mình và nói rằng nó tuân thủ tiêu chuẩn OData, vì người dùng đã quen với OData có thể sử dụng dễ dàng mà không mất nhiều thời gian đọc tài liệu API.

Nhược điểm: Mặc dù OData rất tuyệt trong việc phơi bày cơ sở dữ liệu cơ bản, nhưng đặc tả này không bao gồm hỗ trợ cho các giao dịch và không thể được sử dụng trong các ứng dụng mà chúng tôi có thể có dịch vụ RESTful phục vụ cả giao diện DB cũng như giao diện giao dịch.