Tiêu chuẩn vàng cho API trang web là gì? Twitter, Flickr, Facebook, v.v.

Question

Dường như có hai loại API cho các trang web hiện nay.

1. API cho phép chức năng của trang web được mở rộng như Facebook, Myspace, vv Các API này dường như rất đa dạng.

2. API cho phép tương tác với chức năng trang web hiện tại như Twitter, Flickr, v.v. Tất cả đều được cho là dựa trên REST, nhưng thực tế chỉ đơn giản là "dữ liệu qua HTTP".

Nếu bạn đang tạo trang web cho phép cả tiện ích mở rộng chức năng và tương tác bên ngoài, bạn sẽ sử dụng API nào làm mô hình tham chiếu?

Answer 1

Tôi sẽ xem OpenSocial, một phong trào để tạo Tiêu chuẩn API cho các mạng xã hội. Họ sử dụng REST cho điều này và có cách tiếp cận tập trung 'người dùng'. Nhưng đây là một cách tiếp cận tài liệu rất tốt có thể giúp ngay cả một trang web không hoàn toàn dựa trên xã hội. Nếu bạn đang tìm kiếm một số triển khai mã bên trong, hãy xem hệ thống móc Drupals và Wordpress.

http://code.google.com/apis/opensocial/

Answer 2

Nó sẽ phụ thuộc vào đối tượng mục tiêu của bạn. Nếu đó là các cửa hàng .net thì xà phòng có lẽ không quan tâm đến sự tập trung khôn ngoan khác vào REST vì nó có thanh nhập thấp hơn nhiều. Từ đó, hãy xem các API của trang web nhắm mục tiêu đến cùng một người bạn muốn. Bằng cách này api của bạn sẽ cảm thấy quen thuộc.

Answer 3

Tôi không có kinh nghiệm với những người khác, nhưng ngay cả khi nó đã phát triển qua nhiều năm, Facebook API vẫn còn khủng khiếp. Nó không đến bất cứ đâu gần như là một "tiêu chuẩn vàng". Thay vào đó, nó là một cái gì đó mọi người đấu tranh thông qua và nghiến răng của họ bởi vì một khi họ cuối cùng đã làm cho nó đúng, nó có thể thêm rất nhiều giá trị.

Answer 4

Chúng tôi đang thực hiện một số nghiên cứu trong lĩnh vực này. Không phải là rất nhiều trong đó về "tiêu chuẩn vàng" cho tài liệu tham khảo API trang web.

Các API website phổ biến nhất được tham chiếu là

• Google API http://developers.google.com/api-client-library/java/apis
• Amazon S3 http://docs.amazonwebservices.com/AmazonS3/latest/API/
• Twitter https://dev.twitter.com/
• Facebook http://developers.facebook.com/
• LinkedIn http://developer.linkedin.com/index.jspa
• Delicious http://delicious.com/help/api
• YouTube http://www.youtube.com/dev
• Netflix http://developer.netflix.com/
• Sun API Cloud http://kenai.com/projects/suncloudapis/pages/Home

danh sách khác ở đây:

http://www.pingable.org/the-top-15-web-apis-for-your-site/

Có người đề nghị cuốn sách Restful Web Services như một tài liệu tham khảo tốt về vấn đề này.

(xin vui lòng chỉnh sửa danh sách ở trên để thêm các trang web cấu hình cao khác với các API)

Answer 5

api Last.fm vẫn tiếp tục là một trong những apis tốt nhất duy trì trên mạng. Nó cũng dài hơn nhiều so với hầu hết, bởi vì nó bắt đầu cơ bản như vậy.

http://www.last.fm/api

Answer 6

Một số API mà là đặc biệt tốt:

• Last.FM http://www.last.fm/api (tài liệu tuyệt vời)
• Github http://develop.github.com/ (niềm vui để làm việc với, cũng nghĩ ra)

Answer 7

How To Design A Good API and Why it Matters, cuộc trò chuyện kỹ thuật dài 60 phút của Google theo số Joshua Bloch, có liên quan.

Answer 8

Về danh sách các API lớn của Jeff: Tôi khá chắc chắn rằng chung không không nghĩa "Tiêu chuẩn vàng".

Không cần phải giữ danh sách API phổ biến theo cách thủ công. Để có danh sách, hãy kiểm tra http://www.programmableweb.com/apis/directory/1?sort=mashups.

Vì tôi thích REST là tiêu chuẩn lỏng lẻo, tôi muốn nói rằng API là "Vàng" khi nó có ý nghĩa và là trực quan.

• Twitter (http://apiwiki.twitter.com/),
• Github (http://develop.github.com/) và
• Last.FM (http://www.last.fm/api)

... tất cả làm cho ý nghĩa nhất đối với tôi và cũng nghĩ ra (như Brian đã được chỉ ra).

Trong công việc hàng ngày hiện tại, tôi cũng làm việc rất nhiều với OpenSocial, nơi các URI cảm thấy rất tự nhiên nhưng cũng mở rộng tiêu chuẩn REST theo cách riêng của nó.

Nếu bạn thích nó nghiêm ngặt và an toàn, hãy sử dụng SOAP.

Answer 9

Dường như với tôi rằng tài liệu của API cũng giống như (hoặc nhiều hơn) quan trọng hơn thiết kế thực tế của API.

Bằng văn bản, tài liệu đơn giản sẽ bù đắp cho bất kỳ lỗi thiết kế nào. Đó là những gì tôi đã học được sau khi nhìn vào các liên kết khác nhau được đăng. Cụ thể, tài liệu của Last.fm có vẻ rất tốt: dễ điều hướng và dễ hiểu.

Answer 10

Force (trước đây được biết đến như SalesForce) API: http://www.salesforce.com/us/developer/docs/api/index.htm

Answer 11

Tôi nghĩ rằng cách tốt nhất để trả lời là để liệt kê các đặc các API web tốt thay vì ví dụ trích dẫn. Nếu bạn thích các API của Twitter/Facebook/etc, bạn thấy hấp dẫn về khía cạnh nào của các API này?

tôi sẽ sử dụng những đòn đầu tiên:

1. API Vâng ghi nhận, trong đó có những hạn chế và chính sách sử dụng. Điều này cho phép phát triển nhanh chóng với sự tự tin, thay vì thứ hai đoán những gì các tham số có thể có nghĩa là, và những giá trị trả về là gì.
2. API không công nghệ/ngôn ngữ. Các API tốt nên dễ sử dụng, cung cấp cùng chức năng, trên một loạt các ngôn ngữ và nền tảng.
3. API được hỗ trợ tốt. Luôn có lỗi. Người duy trì đáp ứng dẫn đến nhiều API có thể sử dụng được
4. bộ API phân lớp. Khi các API được sắp xếp gọn gàng, nhiều nhà phát triển có thể tiêu thụ các phần mà họ cần mà không cần phải kéo vào các lớp không liên quan. Thêm vào đó, nó buộc người sáng tạo phải suy nghĩ kỹ về API sạch sẽ và được hợp thành hóa.

Vui lòng thêm thêm vào nhận xét.

Answer 12

Sau khi làm việc với một số ít, tôi sẽ có được quyền xuống để nó

• Facebook

  • TỐT: sạch sẽ và tương đối phù hợp. Thực hiện tốt và hầu hết mọi thứ đều hợp lý. FQL khá gọn gàng. Các tùy chọn XML và JSON. Không có quan niệm trước về định dạng phản hồi ngoài những gì bạn thực sự cần
  • BAD: Thay đổi thường xuyên và không có cảnh báo. thư viện api 'chính thức' khá là tồi tệ. tài liệu của nhiều cuộc gọi kém hoặc mất tích. xác thực phi tiêu chuẩn (một số có thể gọi tốt này?)

• Myspace

  • TỐT: các tiêu chuẩn mở (OAuth xác thực, Opensocial endpoint)
  • BAD: thường bị phá vỡ. Việc sử dụng oauth rất không chuẩn và phá vỡ hầu hết các thư viện khách hàng. thư viện khách hàng chính thức là khủng khiếp.

• Photobucket (từ chối trách nhiệm: Tôi đã viết phía máy chủ của api photobucket)

  • TỐT: tiêu chuẩn mở xác thực (oauth). xml, json, thậm chí cả định dạng mảng tuần tự hóa php như các tham số phản hồi. REST trung thành (nhận/đặt/xóa/đăng lên url 'danh từ').
  • BAD: không có nhiều thư viện khách hàng. Thách thức kiến ​​trúc với thư viện chuẩn oauth (người dùng sống trên tên miền phụ, cuộc gọi phải được thực hiện cho tên miền phụ, vì vậy url phải thay đổi).

• Twitter

  • TỐT: khá phù hợp (mặc dù api vs api tìm kiếm có diffs). Thực hành REST tốt. Xác thực OAuth cũng như hỗ trợ Oldschool Basic.
  • BAD: tỷ lệ lỗi (khá nhiều phù hợp với phần còn lại của twitter mặc dù). Định dạng lẻ của một số giá trị trả lại (như định dạng ngày tháng).

đặc điểm lý tưởng

• Tôi không bán trên REST 'khắt khe'. PUT và DELETE gây ra sự cố trong một số ngôn ngữ của khách hàng. GET và POST dường như là đủ với 'động từ' thích hợp. Ngoài ra, tên chức năng giống RPC là OK với tôi miễn là chúng hợp lý và thậm chí là một phần của URI. Trong trường hợp đó, IDS đối tượng vẫn cần phải rất nhất quán mặc dù.
• Xác thực/ủy quyền chuẩn. Basic/Digest có thể được, nhưng tôi là một fan hâm mộ của OpenID/oAuth (hoặc WRAP nếu bạn muốn có được cạnh chảy máu). Lăn riêng của bạn có nghĩa là bạn phải giải thích 100% của nó, và có khả năng viết thư viện khách hàng cho tất cả mọi người.
• Kiểu dữ liệu chuẩn. Hãy chắc chắn rằng bạn nhất quán về các kiểu dữ liệu của bạn (hoặc là 'true' hoặc 1, không phải một số kết hợp), và hỗ trợ các tiêu chuẩn chung nhất. Thời gian phải là ISO8601. Vị trí địa lý phải giống như 'GeoRSS, v.v. Bạn nên có thể tạo XSD/relaxNG/bất kỳ trình xác thực nghiêm ngặt nào cho các loại trả về của mình. Mong đợi các tiêu chuẩn tương tự từ các yếu tố đầu vào của bạn.
• Cấu trúc trả lại đơn giản. có một số lợi ích đối với XML-RPC/JSON-RPC ở chỗ bạn biết bạn đang lấy lại cái gì, nhưng trong mọi trường hợp, nếu tôi không thể phân tích cú pháp kiểu trả về của bạn với JSON hoặc một cái gì đó như SimpleXML của PHP và sắp xếp nó thành một băm, tôi sẽ tức giận.
• Hỗ trợ mở rộng/mở rộng mà không bị vỡ. Không mã hóa chính bạn vào một góc và làm cho nó khó thêm vào API của bạn. Hãy cố gắng đưa ra quyết định tốt về phía trước mà bạn sẽ không thay đổi liên tục.
• Tài liệu! Hãy chắc chắn rằng nó tốt, và giải thích tất cả mọi thứ. Thậm chí sau đó nó sẽ không đủ tốt, vì vậy hãy chắc chắn rằng bạn có thời gian dành riêng để làm việc trên nó và một diễn đàn hỗ trợ hoặc bất cứ điều gì để giữ cho nó được cập nhật.

Vì vậy, điều đó đang được nói ... điều gì đó giữa Facebook và Twitter. Tất nhiên tôi là một phần của một số công cụ chúng tôi có trên Photobucket, nhưng tôi cũng ghét một số của nó.

Answer 13

AtomPub là tiêu chuẩn vàng vì nó được thiết kế bởi một số tâm trí sáng nhất trên internet. Bạn không thể đi quá xa sai bằng cách sử dụng iit làm cơ sở. Đó là những gì google và msft làm.

Answer 14

Có một câu hỏi tương tự với điều này không nhận được nhiều hành động, nhưng nghĩ rằng sẽ tốt khi liên kết với nó.

What web APIs would you most want to replicate or are the most popular?

Answer 15

Nếu tôi được thiết kế một api web ngày hôm nay cho một trang web hiện có, giả sử các trang web được thiết kế tốt đối với việc sử dụng đúng đắn của HTTP, tôi sẽ sử dụng các trang web hiện có như thiết kế với hướng dẫn.

Lấy Stack Overflow làm ví dụ, nó có toàn bộ không gian URI đã được ánh xạ ra. Nó có một bộ hoàn chỉnh các kết nối được xác định giữa các biểu diễn khác nhau. Người dùng của trang web đã quen thuộc với cấu trúc trang web và do đó cấu trúc API đã quen thuộc.

Chỉ phần duy nhất cần thay đổi là nội dung của các biểu diễn, để loại bỏ tất cả đánh dấu không cần thiết. Nó sẽ là cần thiết để thêm vào một vài liên kết templated thêm để cho phép cho các tìm kiếm hiện chỉ có thể truy cập thông qua javascript.Ví dụ: tìm kiếm người dùng không dễ dàng phát hiện được qua điều hướng vì hiện tại liên kết được xây dựng qua javascript.

Thực sự quyết định khó khăn là loại phương tiện nào sử dụng. Bạn có thể sử dụng xương trần html với đánh dấu siêu dữ liệu kiểu RDFa, hoặc tự nhiên và sử dụng định dạng Microdata mới trong Html5. Hoặc, bạn có thể trả về loại phương tiện tùy chỉnh dựa trên xml hoặc Json. Một cái gì đó như application/vnd.stackoverflow.question + xml, vv Các loại phương tiện truyền thông tùy chỉnh làm cho phiên bản thực sự dễ dàng, nhưng nó là ít có thể truy cập cho khách hàng mà không được thiết kế để truy cập StackOverflow trực tiếp. Có thể sử dụng các loại tùy chỉnh kết hợp với nguồn cấp dữ liệu Atom gần như đã có trong StackOverflow,

Thiết kế api trên web thực sự không khác với thiết kế trang web, ngoài thực tế là bạn đang phân phối nội dung sẽ được tiêu thụ bởi một chương trình không phải là trình duyệt web.

Điều bạn không muốn làm là tạo lớp truy cập dữ liệu dựa trên Http. Điều đó cũng giống như thể hiện đồ lót của bạn với thế giới. Trang web hiện tại được tối ưu hóa cho tất cả các tình huống sử dụng phổ biến, nhiều mẫu truy cập api sẽ giống nhau, vì vậy hãy sử dụng lại "các khung nhìn" đã được tạo. Nó có thể là cần thiết để thêm một vài liên kết thêm ở đây và ở đó để làm cho nó một chút nhanh hơn cho các chương trình để có được những dữ liệu mà họ muốn, nhưng những người có thể được tăng thêm khi nhu cầu phát sinh.

Các trang web bằng văn bản đã là các API rất hiệu quả cho các trình duyệt web, thực sự không cần phải quay lại bảng vẽ để hỗ trợ bất kỳ loại ứng dụng khách nào khác. Cấu trúc API không cần phải thay đổi, chỉ là nội dung được phân phối.