웹 앱용 API를 빌드 할 것이며 사람들이 우수 사례로서 제안 할 수있는 것에 관심이 있습니다.좋은 (웹) API를 작성하는 방법
버전 1 (버전 1은 시스템의 특정 부분 만 제어 할 수 있고 버전 2는 더 많이 제어 할 수 있지만 버전 1과 호환되지 않는 인증 수행 방식이 변경 될 수 있음)), 사용자가 로그인하는 데 사용하는 표준 사용자 이름/비밀번호와 인증이 구분됩니다 (악의적 인 도구를 사용하는 경우 API가 허용하는대로 모든 것을 가장 할 수는 없습니다).
다른 아이디어가 있거나 누구나 사용했던 API가 좋은 사이트의 예가 있습니까?
RESTful Web Services 책을 읽어보십시오.이 책에서는 실용적인 방법으로 REST를 사용하는 방법을 간략하게 살펴보고, 자신감을 갖고 시작하기에 충분한 시간을 최대한 빨리 얻을 수 있습니다. 기존 API를 보는 것보다 유용합니다. 디자인 선택과 절충에 대해서도 설명하기 때문입니다.
REST을 사용하십시오.
RESTful 웹 서비스 아키텍처는 구현하기 쉽고 의도 한대로 HTTP의 장점과 의미를 사용합니다. 웹과 마찬가지로 리소스 지향적입니다.
Amazon Web Services 등 Google 제품 및 기타 제품은 REST API를 통해 제품과 상호 작용할 수 있습니다.
내가 입증 된 API를 한 번 봐 걸릴 것REST를 사용하십시오.
API에 대한 표준을 읽거나 널리 사용되는 아이디어를 복사하십시오.
사용자를 인증 할 때주의하십시오.
매우 간단하게 시작하십시오.
일을 확인하기 위해 API를 사용하는 사이트를 구축하십시오 (유용하지는 않지만). 아마도 모바일 버전의 사이트를 구축하거나 API를 많이 사용해야 할 수도 있습니다.
1) 버전 번호를 매개 변수로 전달하는 대신 URL로 직접 가져 오면 각 버전 범프와 함께 API 네임 스페이스의 구성을 자유롭게 변경할 수 있습니다.
2) URL을 가능한 한 단순하지만 (단순하지는 않지만) 단순한/간결하게 유지하면서 URL을 최대한 아름답게 꾸미십시오.
3) 각 응답에 대해 찾을 수있는 최상의 HTTP 상태 코드를 항상 찾습니다 (예를 들어 202와 207을 잊지 마세요).
4) 파시스트 매개 변수 유효성 검사 논리 및 유익한 오류 메시지를 구현합니다.
5) 매개 변수 대신 HTTP 요청 헤더를 사용하십시오 (예 : 클라이언트가 응답의 원하는 데이터 형식을 지정할 수 있도록 허용).
6) 다른 클라이언트 잠재 고객이 사용하는 URL이 URL 트리의 "루트"근처에서 분리되는 방식으로 "명사"를 구성하십시오. 이렇게하면 필요한 경우 여러 다른 사용자를 위해 다양한 인증 메커니즘을 적용하기가 더 쉬워집니다 URL 트리의 다른 부분을 다른 서버에 매핑 할 수도 있습니다).
7) API와 동일한 도메인에서 일반 웹 페이지를 제공하고 동일한 인증 자격 증명을 사용하는 경우 XSRF 취약성을 피하기 위해 API 요청에 X-Requested-With 헤더가 필요합니다.