57
Opened this issue · 5 comments
RESTful API 설계 가이드
- RESTful API 설계 가이드 본 문서는 REST API를 좀 더 RESTful 하게 설계하도록 가이드할 목적으로 만들어졌다. 따라서, 기본적인 REST API 개념 설명은 아래의 링크로 대신한다. REST API 제대로 알고 사용하..
개발자 친화적인 utterances 댓글 위젯 추가합니다.
지금 보시는 이 포스트가 가장 조회수가 높고 파생되는 질문도 존재합니다.
http://disq.us/p/2a3dawr 이 질문에 대한 답변이 길어질 것 같아 아예 포스트로 작성한 내용도 있습니다. https://sanghaklee.tistory.com/70
좀 더 개발자 친화적이고 질문에 대해 효과적으로 답변할 수 있는 방법에 대해 평소 고민하다, 우연히 utterances라는 서비스를 알게 되어 추가했습니다.
기존 disqus는 유지합니다.
감사합니다, 잘 읽었습니다.등 가벼운 인사를 남기시는 분들도 꽤 많습니다.또한, disqus는 facebook, twitter, google 등으로 로그인할 수 있기 때문에 접근성이 좋습니다.
github 계정이 없거나, 잘 사용하지 않는 방문자분들도 많을 것이라 생각합니다.
플랫폼이 여러 개인 것을 좋아하지 않지만, 기존 댓글들을 버리기 아깝고 두 플랫폼 모두 장-단이 뚜렷하여 모두 제공합니다.
disqus, utterances 어떤 경로든 댓글 주신 분들 모두 감사합니다!
안녕하세요. 좋은글 감사 드립니다
보안상 PUT, DELETE 를 사용하지 못할경우에 url은 어떤식으로 가는게 좋을까요? Url에 행위를 쓰는건 안좋다고 하셔서요..
결론, 일반적인 경우에선 하지 않는 것이 좋으나, 강제성은 없기 때문에 각 상황에 맞게 자체 가이드를 만들어서 URL에 행위를 포함하여 쓰시면 될 것 같습니다.
다음으로 예를 들면, 아래와 같은 CRUD를 제공하는 API를 계획할 때 질문자분의 상황처럼 PUT, DELETE를 사용하지 못할 때:
POST /users
GET /users
GET /users/1
PUT /users/1 - 사용 불가
DELETE /users/1 - 사용 불가
아래와 같이 그 의미가 명확히 나타나도록 하셔도 됩니다.
POST /users/1/update
GET /users/1/delete
- PUT 대신 PATCH를 사용하라는 등의 답변은 하지 않겠습니다.
- POST /users/1/delete로 정해도 상관없을 것 같습니다.
- 제가 GET을 먼저 쓴 이유는 DELETE는 GET과 유사하게 기본적으로 HTTP body를 포함하지 않기 때문입니다.
Url에 행위를 쓰는 건 안 좋다고 한 이유는 다음과 같습니다.
HTTP를 이용하는 REST API는 HTTP method가 행위를 포함합니다.
따라서, URL에 행위를 쓰는 것은 다음과 같은 부작용이 있습니다.
- 불필요한 중복
- HTTP method와 URL에 나타난 행위 간 불일치로 인한 혼동
블로그 글의 제목처럼 설계 가이드기 때문에 각 상황에 맞는 가이드를 따로 만드시면 됩니다.
API DOCS와 개발 코드에 주석으로 왜 이러한 URL을 가져갔는지에 대한 설명이 있다면 더 좋을 것 같습니다.
블로그 내용에서도
일부 규칙들은 기존에 존재하는 회사 규칙 때문에 보편적인 REST API의 철학과 다를 수 있다.라고 썼습니다.
또한, 외부로 공개되는 API의 경우 RESTful 스럽게 만드는 것에 신경을 많이 쓰는 것이 좋지만, 공개되지 않는 내부 API의 경우라면 RESTful 한 API에 너무 얽매이시지 않으셔도 될 것 같습니다.
안녕하세요. 제가 요새 고민하고 있는 것을 이미 체계적으로 정리 하신 것을 보고 왜 구글이 이 글을 먼저 검색해 주지 않았나 하는 아쉬움을 느끼게 되네요. ㅎㅎ 너무 잘 읽었습니다.
한가지 질문드리고 싶은것은
8.3. Filtering 에서
/user 를 filtering 을 하고 싶을때 url 을 어떤 포맷으로 하는지 예시가 있을 까요?
<, <= 등을 사용 한다고 했는데 url 에 어떻게 표현이 되는지 궁금합니다.
/user?userId=abc 이런 식인가요?
/user?filter=userId=abc 이런 식일까요?
안녕하세요. 일단, 필자가 예전에 설계한 API는 다음과 같았습니다.
?q=user_id=tester,status=3
?q=: 쿼링한다는 의미- q=
{}에서{}이 부분을 파싱하여 필터링 객체로 변환하면 됩니다. user_id=tester: equal filtering을 의미합니다.,: and 조건으로 filtering을 의미합니다.
- q=
필자가 설계한 API에서 비교 연산에 대한 필터링 기능은 제공하지 않았지만, 질문에 대해 조금 생각해보면
?q=age>=20
- 이런 식으로 할 것 같습니다.
?q=으로 묶은 이유는 질문자의 예시처럼 바로 userId=abc 이라고 할 수 있으나, uri-querying을 좀 더 다양하게 사용하기 위함입니다.
/user?filter=userId=abc&order=-userId
filter: 필터링 그룹order: 오더링 그룹order=-userId: 결과가 리스트인 경우 userId 내림차순으로 응답
Q. 종종 여러건 조회가 필요할경우는 어떤식으로 설계해야 될까요?
ex) /phone/010-1234-5678
구조라면 보통 get으로 만들건데
핸드폰 번호를 천개 정도 넣을 수 있게끔 만들어야할 경우에요
A. Query string 이용합니다.
/phone/010-1234-5678
/phone?number=010-1234-5678,010-7777-8888