URL에서 제목을 사용해야합니까?

현재 여러 웹 응용 프로그램이있는 사이트에서 일관된 명명 규칙을 결정하고 있습니다. 역사적으로 나는 '모든 글자를 소문자로'옹호했습니다. URL을 만들 때 :

http://example.com/mysystem/account/view/1551

그러나 지난 1 년 동안, 특히 ASP.NET MVC를 사용하기 시작하고 REST 기반 URL을 더 많이 다루기 때문에 URL에서 각 섹션 / 단어의 첫 글자를 대문자로 쓰는 팬이되었습니다. 쉽게 읽을 수 있습니다 (imho).

http://example.com/MySystem/Account/View/1551

우리는 사람들이 상황에서 아니에요 필요로 그 드라이버 자체 없다, 그래서 읽기 또는 URL을 이해 할 수 있도록. 우리가 추구하는 가장 중요한 것은 합리적이고 합리적인 일관된 접근 방식입니다.

어떤 방법 으로든 일하는 것이 좋다고 선언하는 표준이나 다른 것보다 선호를 선택하는 (적어도 현실적으로 현대적인) 설정에서 발생할 수있는 문제가 있습니까? 현재이 토론에 대한 일반적인 합의는 무엇입니까?

선택은 주로 장식 적이므로 (대부분의 시스템은 대소 문자를 구분하지 않으며 사용자는 확실히 그렇지 않습니다), 나는 당신을 행복하게 만드는 방법을 제안합니다. 응용 프로그램 내에서의 일관성은 선택한 방식이 아니라 핵심 입니다.

ASP.Net을 사용하면서 PascalCase 접근 방식을 사용하는 것이 좋습니다. 이는 Microsoft 프레임 워크 (시스템 라이브러리 등) 내에 존재하는 경향이 있기 때문입니다. 그러나 일관성이 아닌 "모범 사례"는 없습니다.

대부분의 브라우저는 Google을 홈페이지로 사용하는 많은 사람들이 페이스 북을 검색하고 클릭 할 때까지 사용자로부터 URL을 숨기는 작업을 상당히 잘 수행합니다. 브라우저.

내부 웹 사이트의 경우 일관성이 유지되는 한 중요하지 않습니다.

외부의 공개 대면 사이트의 경우 Linux / Apache 웹 호스팅의 표준 인 소문자를 사용하는 것이 좋습니다. 내가 기억 하듯이 일부 Firefox 버전은 IE와 다르게 URL 케이싱을 처리하는 것으로 보입니다. 이것은 Chrome에도 적용될 수 있습니다.

일관된 케이스를 갖는 것도 검색 엔진 최적화에 중요합니다. Google에서 lower-case.aspx 및 Lower-Case.aspx를 중복 된 콘텐츠가있는 다른 페이지로 보지 않기를 바랍니다. 그들의 알고리즘은 이러한 잘못된 신원을 막으려 고하지만 때때로 발생하며 페이지에 불이익을 줄 수 있습니다.

사용자가 원하는대로 입력 할 수있는 한 실제로 중요하지 않습니다. 개인적으로, 나는 선호 TitleCase하지만, 동의하지 않는 사람들이 많이 있습니다. 일관성이 있다면 아무도 신경 쓰지 않을 것입니다.

웹 서버 http://foo.com/HelloWorld로 이동하려고 할 때 어떤 이유로 표시 할 수없는 경우 http://foo.com/helloworld모두 소문자를 선택해야합니다. 요즘 사람들은 전체 URL을 거의 입력하지 않지만 대문자를 사용하지 않고도 전면 주소에 액세스 할 수 있어야합니다.

MVC를 사용하기 시작했다면 REST 추상화에 "누설"되어서는 안됩니다. 단어 사이에 대시가있는 모든 소문자 URL을 사용해야 할 이유가 있습니다. 도메인 이름이 아닌 URI는 대소 문자를 구분합니다. 모든 것을 소문자로 구분하고 단어를 구분하기 위해 대시를 사용하면 많은 추측 작업과 일회성을 제거하고 프록시 서버 (nginx, nodejs, apache ...)를 사용하면 모든 것이 깨지기 시작하지 않습니다. 갑자기 대소 문자를 구분하기 때문입니다.

"MiXeD-CaSe NaMeS. URL을 혼합하여 대문자 및 소문자로 문자를 혼동하지 마십시오. 소문자를 고수하고 추측하지 마십시오. 사용자는 실제로 대소 문자를 혼합하여 URL을 입력하고 서버에서이를 정규화하여 적절한 사례를 제공합니다. "

TLD (최상위 도메인)는 대소 문자를 구분하지 않습니다 및 Windows 경로가 자본과 파스칼 케이스의 조합을 사용하는 반면, 우리의 응용 프로그램 경로, 또는 구성 요소가 거기에, 일반적으로 표준 경우에 정규화 들어오는 요청 경로에 민감 이후 /format/JSON/및 /format/json/이에 대한 요청입니다 다른 형식과 두 가지 별개의 리소스를 참조하십시오.

http://www.somewebsite.com/Having/URLs/That-Look-Something-Like-This/를 볼 때마다 개발자의 의도가 주로 나머지 부분과 약간 다르게 보이는 것처럼 느껴졌지만 아무것도 아닙니다. 혁신 성 및 가독성 향상에 도움이되지 않습니다. 특히 분석에 경합하는 다른 문자 인 I 및 l , O 및 0이 있으므로 더욱 그렇습니다 .

나는 어떤 합의도 알지 못합니다 .URL의 특정 부분 만 대문자로 쓰는 것만으로도 가독성에 긍정적 인 영향을 줄 수 있으며 누군가 어딘가에 이미 올 것이라고 확신하기 때문에 하나도 있어야한다고 생각하지도 않습니다 URL에 대소 문자를 적용 할 때 흥미로운 아이디어를 제공합니다.

그러나 대부분의 웹 서버가 Linux에서 실행되고 있으며 개발자가 입력 텍스트가 대소 문자를 구분하기 때문에 항상 수신 텍스트 데이터를 표준화한다는 사실로 판단하면 모든 작업이 어떻게 진행되는지 고심하고 있습니다.

사용상의 이유로 타이틀 케이스를 사용하지 마십시오 ! MOBILE 휴대 전화 에서 다른 사례 URL에 대해 얼마나 많은 시간을 소비하고 클릭을 수행해야하는지 상상해보십시오 .