웹 사이트 API의 표준은 무엇입니까? Twitter, Flickr, Facebook 등
오늘날 웹 사이트 용 API에는 두 가지 범주가있는 것 같습니다.
Facebook, Myspace 등과 같이 사이트의 기능을 확장 할 수있는 API. 이러한 API는 매우 다양해 보입니다.
Twitter, Flickr 등과 같은 기존 사이트 기능과 상호 작용할 수있는 API. 이들은 모두 REST 기반이라고 주장하지만 실제로는 단순히 "HTTP를 통한 데이터"입니다.
기능 확장과 외부 상호 작용을 모두 허용하는 웹 사이트를 만드는 경우 참조 모델로 사용할 기존 API는 무엇입니까?
우리는이 분야에서 직접 조사를하고 있습니다. 웹 사이트 API 참조에 대한 "골드 표준"측면에서 많은 것은 아닙니다.
가장 일반적인 웹 사이트 API는 다음과 같습니다.
- Google API http://developers.google.com/api-client-library/java/apis
- Amazon S3 http://docs.amazonwebservices.com/AmazonS3/latest/API/
- 트위터 https://dev.twitter.com/
- 페이스 북 http://developers.facebook.com/
- LinkedIn http://developer.linkedin.com/index.jspa
- 맛있는 http://delicious.com/help/api
- 유튜브 http://www.youtube.com/dev
- 넷플릭스 http://developer.netflix.com/
- 썬 클라우드 API http://kenai.com/projects/suncloudapis/pages/Home
여기에 또 다른 목록 :
http://www.pingable.org/the-top-15-web-apis-for-your-site/
누군가 는 이것에 대한 좋은 참조로 Restful Web Services 책을 추천했습니다 .
(위 목록을 자유롭게 편집하여 API가있는 다른 유명 웹 사이트를 추가하십시오)
좋은 API를 디자인하는 방법과 중요한 이유 는 Joshua Bloch 의 60 분 Google 기술 강연 입니다.
몇 명과 함께 작업 한 후 바로 시작하겠습니다.
페이스 북
- GOOD : 깨끗하고 비교적 일관성이 있습니다. 잘 수행되고 대부분의 일이 논리적으로 합리적입니다. FQL은 꽤 깔끔합니다. XML 및 JSON 옵션. 실제로 필요한 것 외에 응답 형식에 대한 사전 개념이 없습니다.
- BAD : 경고없이 자주 변경됩니다. '공식'API 라이브러리는 꽤 끔찍합니다. 많은 통화에 대한 문서가 불량하거나 누락되었습니다. 표준이 아닌 인증
내 공간
- GOOD : 개방형 표준 (oAuth 인증, Opensocial 엔드 포인트)
- BAD : 종종 망가졌습니다. oauth의 사용은 매우 비표준이며 대부분의 클라이언트 라이브러리를 손상시킵니다. 공식 클라이언트 라이브러리는 끔찍합니다.
Photobucket (면책 조항 : 저는 photobucket api의 서버 측을 작성했습니다)
- GOOD : 개방형 표준 인증 (oauth). xml, json, 심지어 php 직렬화 된 배열 형식을 응답 매개 변수로 사용합니다. 충실한 REST ( '명사'URL 가져 오기 / 넣기 / 삭제 / 게시).
- BAD : 클라이언트 라이브러리가 많지 않습니다. 표준 oauth 라이브러리의 아키텍처 문제 (사용자는 하위 도메인에 있으며 하위 도메인을 호출해야하므로 URL을 변경해야 함).
트위터
- GOOD : 꽤 일관 적입니다 (API 대 검색 API에는 차이가 있음). 좋은 REST 관행. OAuth 인증 및 oldschool Basic 지원.
- 나쁨 : 오류율 (다른 트위터와 거의 일치 함). 일부 반환 값의 홀수 형식 (예 : 날짜 형식).
이상적인 특성
- 나는 '엄격한'REST에서 판매되지 않습니다. PUT 및 DELETE는 일부 클라이언트 언어에서 문제를 일으 킵니다. GET과 POST는 적절한 '동사'로 충분합니다. 또한 RPC와 유사한 함수 이름은 논리적이고 URI의 일부인 한 나에게 괜찮습니다. 이 경우에도 객체 IDS는 여전히 매우 일관 적이어야합니다.
- 표준 인증 / 승인. 기본 / 다이제스트는 괜찮을 수 있지만 저는 OpenID / oAuth (또는 블리딩 에지를 얻으려면 WRAP)의 팬입니다. 직접 롤링한다는 것은 100 % 설명해야하고 잠재적으로 모든 사람을위한 클라이언트 라이브러리를 작성해야 함을 의미합니다.
- 표준 데이터 유형. 데이터 유형에 대해 일관성을 유지하고 ( '참'또는 1, 일부 혼합이 아님) 가장 일반적인 표준을 지원해야합니다. 날짜 시간은 ISO8601이어야합니다. Geolocation은 GeoRSS와 같은 '모양' 이어야 합니다. 반환 유형에 대해 XSD / relaxNG / 어떤 엄격한 유효성 검사기를 만들 수 있어야 합니다. 귀하의 입력에서 동일한 표준을 기대하십시오.
- 간단한 반환 구조. XML-RPC / JSON-RPC에는 어떤 이점이 있는지 알고 있지만 어쨌든 JSON 또는 PHP의 SimpleXML과 같은 것으로 반환 유형을 쉽게 구문 분석하고 본질적으로 일관성있는 형식으로 직렬화 할 수 없다면 해시, 나는 화를 낼 것입니다.
- 파손없이 확장 / 확장을 지원합니다. 코너에 직접 코딩하지 말고 API에 추가하기 어렵게 만드십시오. 끊임없이 변하지 않을 좋은 결정을 내 리도록 노력하십시오.
- 선적 서류 비치! 그것의 좋은 것을 확인하고 모든 것을 설명하십시오. 그래도 충분하지 않을 것입니다. 따라서 작업에 시간을 할애하고 지원 포럼 또는 최신 상태로 유지하기 위해 무엇이든해야합니다.
그래서 ... 페이스 북과 트위터 사이에 뭔가. 물론 저는 Photobucket에있는 일부 항목에 부분적이지만 일부는 싫어합니다.
나에게 보인다 문서 의 API는 API의 실제 설계보다 중요한 것처럼 (또는 그 이상).
잘 작성된 간단한 문서는 모든 디자인 결함을 보완합니다. 이미 게시 된 다양한 링크를보고 배운 것입니다. 특히 Last.fm의 문서는 매우 훌륭해 보입니다. 탐색하기 쉽고 이해하기 쉽습니다.
Last.fm의 API는 계속해서 인터넷에서 가장 잘 관리되는 API 중 하나입니다. 기본적으로 그렇게 시작했기 때문에 대부분의 것보다 오래되었습니다.
Jeff의 큰 API 목록에 관하여 : 나는 공통 이 "골드 스탠다드"를 의미 하지 않는다고 확신합니다 .
광범위한 API의 수동 목록을 유지할 필요가 없습니다. 목록을 얻으려면 http://www.programmableweb.com/apis/directory/1?sort=mashups를 확인 하십시오 .
나는 REST를 느슨한 표준으로 좋아하기 때문에 API가 의미가 있고 직관적 일 때 "황금"이라고 말하고 싶습니다 .
- Twitter ( http://apiwiki.twitter.com/ ),
- Github ( http://develop.github.com/ ) 및
- Last.FM ( http://www.last.fm/api )
… 모두 저에게 가장 이해가되며 잘 생각합니다 (Brian이 이미 지적했듯이).
현재의 일상 업무에서도 URI가 매우 자연스럽게 느껴지지만 자체 방식으로 REST 표준을 확장하는 OpenSocial과 함께 많이 작업합니다.
엄격하고 안전한 경우 SOAP를 사용하십시오.
I would check out OpenSocial, a movement to create an API Standard for social network sices. They use REST for this and have a 'user' centric approach. But this is a very well documented approach which might help for even a site that is not totally Social based. If you are looking for some internal code implementations look at Drupals hook system and Wordpress.
http://code.google.com/apis/opensocial/
I think the best way to answer is to list the characteristics of good web APIs instead of citing examples. If you like Twitter/Facebook/etc APIs, what aspect of these APIs do you find attractive?
I'll take a first stab:
- Well documented APIs, including constraints and usage policies. This enables rapid development with confidence, instead of second guessing what the parameters might mean, and what return values are.
- Technology/language agnostic APIs. Good APIs should be easily usable, providing the same functionality, across a wide array of languages and platforms.
- Well supported APIs. There are always bugs. Responsive maintainers result in more usable APIs
- Layered API sets. When APIs are neatly layered, a wide range of developers can consume the pieces they need without needing to pull in extraneous layers. As a plus, it forces the creators to think hard about clean and componentized APIs.
Please add more to comments.
I don't have any experience with the others, but even as it has evolved over the years, the Facebook API is still awful. It doesn't come anywhere near being a "gold standard." Rather, it is something people struggle through and grit their teeth because once they finally get it right, it can add a lot of value.
Some APIs which are notably good:
- Last.FM http://www.last.fm/api (wonderful documentation)
- Github http://develop.github.com/ (pleasure to work with, well thought out)
It will depend on what your target audience is. If it is .net shops then soap is probably okay other wise focus on REST since it has a much lower bar of entry. From there look at website APIs that target the same people you would like to. This way your api will feel familiar.
Force (previously known as SalesForce) API: http://www.salesforce.com/us/developer/docs/api/index.htm
AtomPub is the gold standard because it was designed by some of the brightest minds on the internet. You can't go too far wrong using iit as a basis. That is what google and msft does.
Had a similar question to this which didn't get much action, but thought it would be good to link to it.
What web APIs would you most want to replicate or are the most popular?
If I were designing a web api today for an existing web site, assuming the web site was well designed with respect to its proper usage of HTTP, I would use the existing web site as the design guideline.
Take Stack Overflow as an example, it has the entire URI space already mapped out. It has a complete set of interconnections defined between the different representations. Users of the site are already familiar with the site structure and therefore the API structure would already be familiar.
The only part that needs to change is the content of the representations, to eliminate all unnecessary markup. It would be necessary to add in a few extra templated links to allow for searches that are currently only accessible via javascript. For example, searching for a user is not easily discoverable via navigating because currently the link is built via javascript.
The really tricky decision is what media-type to use. You could use bare bones html with RDFa style metadata markup, or go wild and use the new Microdata format in Html5. Or, you could return a custom media type based on xml or Json. Something like application/vnd.stackoverflow.question+xml, etc. The custom media type makes versioning really easy, but it is less accessible to clients that were not designed to access StackOverflow directly. The custom types could be used in combination with Atom feeds which are mostly already there in StackOverflow,
Designing a web api is really no different than designing a website, other than the fact that you are delivering content that will be consumed by a program that is not a web browser.
What you don't want to do is create an Http based data access layer. That is just like showing your underwear to the world. The existing web site is optimized for all the common usage scenarios, many of the api access patterns are going to be similar, so reuse the "views" that have already been created. It may be necessary to add a few extra links here and there to make it a bit quicker for programs to get the data they want, but those can be added incrementally as the need arises.
Well written web sites are already very effective APIs for web browser clients, it is really not necessary to go back to the drawing board to support any other type of client. The API structure does not need to change, just the delivered content.
'Programing' 카테고리의 다른 글
| Travis-CI를 구성하여 풀 리퀘스트를 빌드하고 중복없이 마스터에 병합하는 방법 (0) | 2020.12.01 |
|---|---|
| Docker 컨테이너를 중지 / 시작하지 않는 파일을 편집하는 방법 (0) | 2020.12.01 |
| DateTime.ToUniversalTime ()은 어떻게 작동합니까? (0) | 2020.12.01 |
| SQL 조인 테이블 명명 규칙 (0) | 2020.12.01 |
| IQueryable, List, IEnumerator의 차이점은 무엇입니까? (0) | 2020.12.01 |