2008-12-14 10 views
11

Tôi biết rằng một số người chơi lớn đã chấp nhận nó và thực sự đang phơi bày một số dịch vụ của họ theo cách tuân thủ APP, đã có. Tuy nhiên, tôi đã không tìm thấy nhiều người chơi khác (nhỏ hơn) trong lĩnh vực này. Bạn có biết bất kỳ ứng dụng/dịch vụ web nào sử dụng APP làm giao thức API công khai không? Điều gì là của riêng bạn có trên AtomPub? Bạn có kinh nghiệm thực tế nào không? Những hạn chế và hạn chế của nó là gì? Bạn có thích AtomPub như phong cách REST của bạn hoặc bạn có một số yêu thích khác? Và tại sao?Giao thức xuất bản Atom trong đời thực

Tôi biết, đây là nhiều câu hỏi, không chỉ một câu hỏi. Điều tôi quan tâm ở đây là đơn giản, mặc dù - làm thế nào tiêu chuẩn APP nhấn thị trường và đặc biệt là làm thế nào nó có vẻ như với sự chấp nhận của nó trong số các nhà phát triển web?

Trả lời

2

nghiên cứu riêng của tôi cho đến nay:

  • Wordpress hỗ trợ AtomPub như giao thức API của nó kể từ phiên bản 2.3
  • GData có lẽ là bắn lớn nhất trong lĩnh vực AtomPub cho đến nay
  • Habari - mới hệ thống blog đầy hứa hẹn quảng bá APP là một trong những tính năng chính của nó
  • BlogSvc.net - máy chủ AtomPub , công cụ blog cho .NET nền tảng, được viết trong C#
  • Jangle - một dự án mã nguồn mở được thiết kế để tạo điều kiện truy cập API để Hệ thống Thư viện
+0

là có thể chia sẻ danh sách được cập nhật –

2

Ngoài ra còn có mod_atom - một module Apache mà các cửa hàng mục trong hệ thống tập tin.

1

Thời gian qua tôi đã kiểm tra (2007 hoặc lâu hơn) Atompub khá phức tạp để thực hiện. Trong khi bạn có thể kết hợp với nhau thứ gì đó phát ra nguồn cấp dữ liệu Atom hợp lệ trong giờ nghỉ trưa, việc triển khai AtomPub là một công việc khá lớn.

Điều đó có thể đã thay đổi do các thư viện và công cụ tốt hơn nhưng vẫn có thể quá phức tạp để các bên nhỏ hơn triển khai chỉ vì nó tuyệt vời.

Và việc thiếu các ứng dụng khách AtomPub gây sát thương sẽ gây ra rất ít hoặc không gây áp lực lên các nhà khai thác máy chủ để cung cấp giao diện AtomPub.

3

Công ty mà tôi đang làm việc, đang phát triển rất nhiều dịch vụ RESTful. Tuy nhiên, không ai trong số họ trưng ra các API công cộng (Theo nghĩa là tất cả các dịch vụ đều được khách hàng của chúng tôi tiêu thụ nội bộ). Lý do tại sao chúng tôi đã đi cho phong cách kiến ​​trúc REST là chúng tôi muốn các dịch vụ của chúng tôi dễ dàng tiêu thụ và quan trọng hơn là mở rộng quy mô tốt. Từ kinh nghiệm thực tế của riêng tôi, tôi đã đi đến kết luận rằng định dạng cung cấp HTTP + ATOM là một ý tưởng hay, với điều kiện bạn muốn giữ mọi thứ linh hoạt (Về mô hình nội dung khác nhau, đính kèm và mở rộng siêu dữ liệu liên quan đến tải trọng), phân tích thống nhất v.v.) ATOM đảm bảo rằng mọi người diễn giải tải trọng một cách thống nhất mà không có bất kỳ phạm vi nào cho sự mơ hồ.

Tuy nhiên, nếu một người không có bất kỳ yêu cầu phức tạp như vậy hoặc không chấp nhận các yêu cầu đó thì định dạng ATOM có thể là một chút phí. (Ví dụ như các yếu tố như Tác giả, Tiêu đề, vv có ý nghĩa hơn trong thế giới blog/RSS và có thể không có ý nghĩa trong miền vấn đề cụ thể của bạn).

Ngoài ra nếu mục tiêu là chỉ cần tuần tự hóa cấu trúc dữ liệu ở một đầu và xây dựng lại ở đầu kia thì hầu hết các khung công tác web (như WCF) đều có định dạng tùy chỉnh hấp dẫn hơn.

Vì vậy, theo ý kiến ​​của tôi ATOM Pub là tốt nếu bạn cần flexiblity về dữ liệu đại diện và nếu sân chơi là rất lớn với các loại khác nhau của khách hàng.

Tuy nhiên, nếu bạn có kiến ​​thức tốt về khách hàng tiềm năng và mẫu sử dụng máy chủ/khách hàng thì định dạng tùy chỉnh có thể là một ý tưởng hay.

Nếu khách hàng là trình duyệt dựa thì các định dạng như JSON rất hấp dẫn.

Hy vọng điều này sẽ trả lời câu hỏi của bạn.