URI에서 단어 구분 기호로 하이픈, 밑줄 또는 낙타 케이스?

인트라넷 앱을위한 HTTP 기반 API를 설계하고 있습니다. 나는 그것이 대단한 계획에서 매우 작은 관심사라는 것을 알고 있지만 URI에서 단어를 구분하기 위해 하이픈, 밑줄 또는 낙타 케이스를 사용해야합니까?

나의 초기 생각은 다음과 같습니다.

낙타

• 서버가 대소 문자를 구분하지 않는 경우 가능한 문제
• 쿼리 문자열 키 ( http://api.example.com ? searchQuery = ...) 에서 상당히 널리 사용되는 것으로 보이지만 다른 URI 부분에서는 그렇지 않습니다.

하이픈

• 다른 대안보다 심미적으로 기쁘다
• URI의 경로 부분에서 널리 사용되는 것 같습니다.
• 야생에서 하이픈으로 연결된 쿼리 문자열 키를 본 적이 없음
• 아마도 (이 신화 일 수 있음) 검색 엔진 최적화에 대한 더 나은

밑줄

• 프로그래밍 언어가 다루기가 더 쉬울 것
• 몇몇 유명한 API (Facebook, Netflix, StackExchange 등)는 URI의 모든 부분에서 밑줄을 사용합니다.

나는 모든 것에 대한 밑줄로 기울고 있습니다. 대부분의 큰 플레이어가 사용하고 있다는 사실은 매력적입니다 ( https://stackoverflow.com/a/608458/360570 참조 ).

크롤링 가능한 웹 응용 프로그램 URL에 하이픈을 사용해야합니다. 왜? 하이픈은 단어를 분리하므로 (검색 엔진이 개별 단어를 색인 할 수 있도록) 단어 문자 가 아닙니다 . 밑줄은 단어 문자이므로 단어의 일부로 간주해야합니다.

Chrome에서 두 번 클릭 : camelCase Chrome에서
두 번 클릭 : under_score Chrome에서
두 번 클릭 : 하이픈 사용

Chrome (Google도 검색 엔진을 제작한다고 들었습니다)이 두 단어 중 하나만 두 단어로 생각하는 방식을 참조하세요

camelCase그리고 underscore또한 사용하는 사용자를 필요로 shift하는 반면, 키를 hyphenated하지 않습니다.

따라서 크롤링 가능한 웹 응용 프로그램에서 하이픈을 사용해야하는 경우 왜 인트라넷 응용 프로그램에서 다른 작업을 수행해야합니까? 기억해야 할 것이 하나 더 적습니다.

REST API의 표준 모범 사례는 낙타 나 밑줄이 아닌 하이픈을 사용 하는 것입니다.

이것은 Oreilly의 Mark Masse의 "REST API Design Rulebook"에서 나온 것입니다.

또한 스택 오버플로 자체는 URL에서 하이픈을 사용합니다. .../hyphen-underscore-or-camelcase-as-word-delimiter-in-uris

워드 프레스와 마찬가지로 : http://inventwithpython.com/blog/2012/03/18/how-much-math-do-i-need-to-know-to-program-not-that-much-actually

하이픈을 권장 하지만 목록에없는 답변도 가정합니다.

전혀

• 우리 회사의 API는 같은 URI를 가지고 /quotationrequests/, /purchaseorders/등등을.
• 인트라넷 앱이라고 말했지만 SEO를 혜택으로 표시했습니다. Google은 다음 검색어에 대한 URL에서 / foobar / 패턴과 일치합니다.?q=foo+bar
• 난 정말 당신이 ServAce85 알 @로 사용자가 주소 표시 줄에 전달 임의의 문자열을 PHP 호출을 실행 고려하지 않기를 바래요!

일반적으로, 그것은 일반적인 인터넷 응용 프로그램이 아닌 인트라넷 응용 프로그램 이기 때문에 걱정할만한 영향을 미치지 않습니다. 특히 인트라넷 이기 때문에 검색 엔진에 인트라넷에 액세스 할 수 없어야하기 때문에 SEO는 문제가되지 않습니다. (있는 경우 인트라넷 앱이 아님).

그리고 소금에 걸 맞는 모든 프레임 워크에는 이미이 작업을 수행하는 기본 방법이 있거나 여러 단어 URL 구성 요소를 다루는 방법을 변경하기가 쉽기 때문에 너무 걱정하지 않아도됩니다.

즉, 다양한 옵션을 보는 방법은 다음과 같습니다.

하이픈

• 하이픈의 가장 큰 위험은 같은 문자 (일반적으로)가 빼기와 숫자 부정 (즉, 빼기 또는 음수 ) 에도 사용된다는 것 입니다.
• URL 구성 요소에는 하이픈 이 어색합니다. 기사 제목에서 단어를 구분하기 위해 URL 끝에 만 의미가있는 것 같습니다. 또는 예를 들어 SEO 및 사용자 명확성을 위해 URL 끝에 추가되는 스택 오버플로 질문의 제목입니다.

밑줄

• 다시 말하지만 URL 구성 요소에서 잘못된 느낌이 듭니다. URL의 흐름 (및 아름다움 / 간단 함)을 깨뜨립니다. 기본적으로 깨끗하고 흐르는 URL 중간에 크고 겉보기 공간이 넓기 때문입니다.
• 그들은 밑줄과 혼합되는 경향이 있습니다. 당신은 사용자가 다른 곳 MS Word 또는 기타 유사한 텍스트 편집 프로그램 또는에 URL을 복사 - 붙여 넣기를 기대하는 경우 (링크처럼 그 밑줄이있는 URL과 스타일을 데리러 수있는 전통적 있습니다) 다음에 할 수 있습니다, 밑줄은 단어 구분 기호로 사용하지 마십시오. 특히 인쇄 할 때 밑줄이있는 밑줄이있는 URL은 밑줄 대신 공백이 있는 것처럼 보입니다 .

낙타 케이스

• 내가 가장 좋아하는 것은 URL이 더 잘 흐르고 이전 두 옵션의 결함이 없기 때문입니다.
• 대문자와 소문자를 구별하는 데 어려움을 겪는 사람들에게는 읽기 가 약간 더 어려울 수 있지만 대부분의 "단어"는 URL 구성 요소 여야하며 /어쨌든 구분되어야하기 때문에 URL에서는 큰 문제가되지 않습니다. . 길이가 "단어"가 2 개를 초과하는 URL 구성 요소가있는 경우 해당 개념에 대해 더 나은 이름을 찾아야합니다.
• 그것은 않는 경우 감도가 가능한 문제를 가지고 있지만, 대부분의 플랫폼이 두 경우를 구분 또는 대소 문자를 구별로 조정할 수 있습니다. 모든 단지의 정말 2가지 경우에 대한 문제는 : A)에 URL을 입력 (우리는 인간 아니기 때문에)에 URL을 입력 인간, 그리고 b)는 프로그래머 오타가 있습니다... 항상 이 그래서, 대소 문자 구분에 관계없이 문제 하나의 경우와 다르지 않습니다.

짧은 답변:

구분 기호로 하이픈이있는 소문자 단어

긴 답변 :

URL의 목적은 무엇입니까?

주소를 가리키는 것이 답이라면 단축 URL도 잘 작동합니다. 쉽게 읽고 관리 할 수 ​​없다면 개발자와 관리자 모두에게 도움이되지 않습니다. 서버의 엔티티를 나타내므로 논리적으로 이름을 지정해야합니다.

하이픈 사용을 권장합니다

URL에 구두점을 사용하는 것이 좋습니다. 의 URL http://www.example.com/green-dress.html는 보다 훨씬 더 효과적입니다 http://www.example.com/greendress.html . URL에서 밑줄 (_) 대신 하이픈 (-)을 사용하는 것이 좋습니다.

프로그래밍 배경에서 나온 camelCase는 공동 단어의 이름을 지정하는 데 널리 사용됩니다.

그러나 RFC 3986 은 URL을 URL의 다른 부분에 대해 대소 문자를 구분하는 것으로 정의합니다. URL은 대소 문자를 구분하므로 키를 낮게 (소문자) 유지하는 것이 항상 안전하며 좋은 표준으로 간주됩니다. 이제는 낙타 사건이 창 밖으로 나옵니다.

출처 : https://metamug.com/article/rest-api-naming-best-practices.html#word-delimiters

여기에 두 세계의 최고가 있습니다.

나는 또한 "좋아요"를 강조하고, 그들에 대한 당신의 모든 긍정적 인 점 외에도 그들에게 특정한 구식 스타일이 있습니다.

그래서 내가하는 일은 밑줄을 사용하고 Apache의 .htaccess 파일에 작은 다시 쓰기 규칙을 추가하여 모든 밑줄을 하이픈으로 다시 쓰는 것입니다.

https://yoast.com/apache-rewrite-dash-underscore/