알씨타운

  REST API URI의 규칙에 대해 알아보기 전에 용어에 대해 간략히 짚고 넘어가도록 하겠습니다.         URI   REST API는 URL를 사용합니다. 오늘날의 웹에서 URI 디자인은 API의 리소스 모델을 명확하게 전달하는 걸작부터 사람들이 이해하기 힘들어하는 것까지 다양합니다.   팀버너스 리 는 "웹 아키텍처의 원칙"이라는 목록에 URI의 불투명성에 대한 메모를 기재하였습니다. "식별자를 사용할 수 있는 유일한 것은 객체를 참조하는 것입니다. 역참조하지 않을 때는 다른 정보를 얻으려면 URI 문자열의 내용을 참조하십시오."   클라이언트는 웹의 연결 패러다임을 따라야 하고 URI를 불완전한 식별자로 취급해야 합니다.   REST API 디자이너는 REST AP의 리소스 모델을 잠재적 클라이언트 개발자에게 전달하는 URI를 만들어야 합니다. 이번 포스팅에서는  REST API URI의 몇 가지 디자인 규칙 을 소개하고자 합니다.   규칙에 대해 알아보기 전에 이 섹션에서 제시하는 규칙에 따라 URI 형식에 대한 단어는 URI 형식과 관련이 있습니다.  RFC 3986 은 아래와 같이 일반 URI 구문을 정의하였습니다.   URI = scheme "://" authority "/" path [ "?" query ] [ "#" fragment ]       규칙 1 후행 슬래시(/)는 URI에 포함되지 않아야 한다   이것은 URI 경로를 결정하는 마지막 문자로써 반드시 따라야 하는 아주 중요한 규칙 중 하나입니다. 슬래시는 의미가 전혀 없을 뿐만 아니라 혼동을 일으킬 수 있습니다. REST API에서는 클라이언트 개발자에게 넘어가는 API URL에 후행 슬래시가 포함되지 않아야 합니다.   많은 웹 컴포넌트나 프레임워크들은 다음의 두 URI를 동일하게 취급합니다. http://moret...

  React Conf에서 만난 사람들이 저에게 더 좋은 개발자가 되려면 어떻게 해야 하는지 물어봤던 적이 있습니다. 아마 저를 꽤 높은 수준의 프로그래머라고 생각하셨던 것 같습니다. 그래서 저는 이번 기회에 수년 동안 제가 어떤 방식으로 프로그래밍에 접근해 왔었는지 "멘탈 모델"을 적어보는 시간을 가지려고 합니다.   일단 저에 대한 정보를 몇 가지 말씀 드리자면, 저는 32세이고, 10년 이상의 경력을 가지고 있습니다. 최근에야 비로소 제가 하고 있는 일에 자신감을 가졌습니다. 하지만 전 여전히 제자신을 끊임없이 의심하고 있습니다. 아마 이런 느낌은 영원히 사라지지 않을 것 입니다. 여러분들은 이 기분을 무시하고, 열심히 개발을 하고, 경험을 쌓으시길 바랍니다.       이번에 제가 말씀드리는 것들은 프로그래밍 기술을 향상시키기 위한 팁들입니다. 포스트를 읽으시며 가장 나에게 적합한 방법이 무엇인지 찾으시길 바랍니다. 제가 말씀드리는 팁들은 그저 저에게 도움이 된 것들일 뿐입니다.   당신에게 영감을 주는 사람을 찾되, 맹목적으로 믿지는 마세요   수년동안 새로운 기술과 정보를 습득하기 위해 많은 사람들의 자료를 찾았었습니다. 저는 그들의 말이 옳다고 믿었고, 그들이 작업한 것들을 공부하며 많은 것들을 배웠습니다. 그 사람들은 매우 생산적이였고, 똑똑했고, 저나 다른사람들에게 영감을 주었습니다. 여러분들도 그런 사람들을 찾아 영감을 받고 배우시길 바랍니다.   하지만 그들의 말이 맹목적으로 전부 옳다고 생각하지는 않길 바랍니다. 트위터에서 봤을 때, 엄청 대단해 보이는 것들도, 실제로 작동 방식을 보면 별반 크게 다를 바가 없습니다. 모든 수단과 방법을 가리지 않고, 작동하는 코드를 쓰려고 하는 것일 뿐입니다. 만약 그 사람들의 의견에 동의가 되지 않는 경우가 생기시다면, 그들에게 의견을 제시하고 그 과정을 배우시길 바랍니다. 저에게 가장 생산적인 대화 중 일부도 이런식의 과정을 통해 ...