REST API에 대한 명명 규칙이 있습니까? [닫은]

REST API를 생성 할 때 API 내에서 명명 규칙에 대한 지침 또는 사실상의 표준이 있습니까 (예 : URL 끝점 경로 구성 요소, 쿼리 문자열 매개 변수)? 낙타 모자는 표준입니까, 아니면 밑줄입니까? 다른 사람?

예를 들면 다음과 같습니다.

api.service.com/helloWorld/userId/x

또는

api.service.com/hello_world/user_id/x

참고 : 이는 RESTful API 디자인의 문제가 아니라 사용되는 최종 경로 구성 요소 및 / 또는 쿼리 문자열 매개 변수에 사용할 명명 규칙 지침입니다.

모든 지침을 주시면 감사하겠습니다.

낙타 모자를 피해야한다고 생각합니다. 표준은 소문자를 사용하는 것입니다. 또한 밑줄을 피하고 대신 대시를 사용하십시오.

따라서 URL은 다음과 같아야합니다 (요청한 디자인 문제는 무시하십시오 :-))

api.service.com/hello-world/user-id/x

Dropbox , Twitter , Google 웹 서비스 및 Facebook 용 REST API는 모두 밑줄을 사용합니다.

일반적인 웹 리소스에 대한 URI를 자세히 살펴보십시오. 그것들이 당신의 템플릿입니다. 디렉토리 트리를 생각하십시오. 간단한 Linux와 같은 파일 및 디렉토리 이름을 사용하십시오.

HelloWorld정말 좋은 클래스는 아닙니다. "사물"인 것 같지 않습니다. 그럴 수도 있지만 매우 명사와는 다릅니다. A greeting는 것입니다.

user-id가져 오는 명사 일 수도 있습니다. 그러나 요청 결과는 user_id 일뿐입니다. 요청 결과가 사용자 일 가능성이 훨씬 높습니다. 따라서, user당신이 가져 오는 명사입니다

www.example.com/greeting/user/x/

이해가 되네요 REST 요청을 일종의 명사구 (계층 구조 (또는 분류 체계 또는 디렉토리)를 통과하는 경로)로 만드는 데 중점을 둡니다. 가능한 경우 명사구를 피하면서 가능한 가장 간단한 명사를 사용하십시오.

일반적으로 복합 명사구는 일반적으로 계층 구조의 다른 단계를 의미합니다. 그래서, 당신은하지 않습니다 /hello-world/user/와 /hello-universe/user/. 당신은 가지고 /hello/world/user/와 hello/universe/user/. 또는 가능하게 /world/hello/user/하고 /universe/hello/user/.

요점은 리소스 간의 탐색 경로를 제공하는 것입니다.

'UserId'는 전적으로 잘못된 접근법입니다. 동사 (HTTP 메소드) 및 명사 접근 방식은 Roy Fielding 이 REST 아키텍처에 대해 의미 한 것입니다 . 명사

1. 컬렉션 것들
2. 일

좋은 명명 규칙 중 하나는 다음과 같습니다.

[POST or Create](To the *collection*)
sub.domain.tld/class_name.{media_type} 

[GET or Read](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[PUT or Update](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[DELETE](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[GET or Search](of a *collection*, FRIENDLY URL)
sub.domain.tld/class_name.{media_type}/{var}/{value}/{more-var-value-pairs}

[GET or Search](of a *collection*, Normal URL)
sub.domain.tld/class_name.{media_type}?var=value&more-var-value-pairs

{media_type}은 json, xml, rss, pdf, png 및 html 중 하나입니다.

끝에 다음과 같이 's'를 추가하여 콜렉션을 구별 할 수 있습니다.

'users.json' *collection of things*
'user/id_value.json' *single thing*

그러나 이것은 당신이 's'를 어디에 놓았는지, 어디에 놓지 않았는지 추적해야 함을 의미합니다. 또한 지구의 절반 (초보자 용 아시아 인)은 명시 적 복수형이없는 언어를 사용하므로 URL이 덜 친숙합니다.

아니요. REST는 URI 명명 규칙과 관련이 없습니다. 하이퍼 텍스트를 통하지 않고 대역 외의 API의 일부로 이러한 규칙을 포함 시키면 API가 RESTful하지 않습니다.

자세한 내용은 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven을 참조하십시오.

도메인 이름은 대소 문자를 구분하지 않지만 나머지 URI는 확실 할 수 있습니다. URI가 대소 문자를 구분하지 않는다고 가정하는 것은 큰 실수입니다.

http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html 에 우리가 생산에 사용한 가이드 라인 목록이 있습니다. 지침은 항상 논란의 여지가 있습니다. 저는 일을 완벽하게하는 것보다 일관성이 더 중요하다고 생각합니다.

낙타 사례가 해당 예제의 문제라고 생각하지 않지만 위 예제의 RESTful 명명 규칙은 다음과 같습니다.

api.service.com/helloWorld/userId/x

오히려 userId를 쿼리 매개 변수 (완전히 합법적 인)로 만드는 것은 내 예제에서 IMO의 리소스를보다 RESTful 한 방법으로 나타냅니다.

Oauth2로 클라이언트를 인증하는 경우 두 개 이상의 매개 변수 이름에 밑줄이 필요하다고 생각합니다.

• client_id
• client_secret

내 (아직 게시되지 않은) REST API에서 camelCase를 사용했습니다. API 문서를 작성하는 동안 모든 것을 snake_case로 변경하려고 생각했기 때문에 다른 매개 변수가 아닌 Oauth 매개 변수가 snake_case 인 이유를 설명 할 필요가 없습니다.

참조 : https://tools.ietf.org/html/rfc6749

REST URL에서 가능한 적은 수의 특수 문자를 사용하는 것이 좋습니다. REST의 장점 중 하나는 서비스의 "인터페이스"를 쉽게 읽을 수 있다는 것입니다. 낙타 케이스 또는 파스칼 케이스는 아마도 리소스 이름 (사용자 또는 사용자)에게 좋습니다. REST와 관련하여 실제로 엄격한 표준이 있다고 생각하지 않습니다.

또한 Gandalf가 옳다고 생각합니다. 일반적으로 REST에서 쿼리 문자열 매개 변수를 사용하지 않고 처리하려는 리소스를 정의하는 경로를 만드는 것이 더 깨끗합니다.

http://api.example.com/HelloWorld/Users/12345/Order/3/etc