Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ohii] Chapter 6. API URL의 설계 & 프로젝트 세팅 #25

Merged
merged 1 commit into from
May 23, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions docs/chapter6/Ch05keyword.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
[REST API]
<REST API>
: REST 아키텍처 스타일의 설계 원칙을 준수하는 API

<REST>
: 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것
: HTTP URI를 통해 자원을 명시하고, HTTP 메서드를 통해 해당 자원에 대한 CRUD를 적용하는 것

<REST 구성 요소>
1. 자원 : URI
2. 행위 : HTTP Method
3. 표현 : JSON/XML …

<REST 특징>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

REST에 관해 더 자세히 설명해주신 것 같아 좋았습니다!

1. server-client 구조
- 자원이 있는 쪽(server), 자원을 요청하는 쪽(client)
2. Stateless(무상태)
- HTTP 프로토콜은 Stateless 프로토콜임 -> REST도 무상태
- client의 context를 서버에 저장하지 않음
- 서버는 각 요청을 완전히 별개의 것으로 인식하고 처리
3. Cacheable(캐시 처리 가능)
- HTTP의 캐싱기능(웹리소스를 사용자의 브라우저나 서버에 임시 저장 후, 동일한 요청이 있을 때 빠르게 제공) 적용 가능
4. 계층화
- 클라이언트는 REST API 서버만 호출
- REST 서버는 다중 계층으로 구성될 수 있음
5. Code-On-Demand(optional)
- 서버로 부터 스크립트를 받아서 client에서 실행
- 반드시 x
6. 인터페이스 일관성
- URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행
- HTTP 표준 프로토콜에 따르는 모든 플랫폼 사용 가능

<REST API 설계 기본 규칙>
1. URI는 정보의 자원을 표현해야 한다.
- 자원은 동사보다는 명사, 대문자보다는 소문자
- 자원의 도큐먼트(객체 인스턴스) 이름은 단수 명사
- 자원의 컬렉션(서버에서 관리하는 디렉터리 리소스) 이름은 복수 명사
- 자원의 스토어(클라이언트에서 관리하는 리소스 저장소) 이름은 복수 명사
2. 자원에 대한 행위는 HTTP 메서드로 표현
- URI에는 HTTP 메서드 들어가면 x
- URI에 동사 표현 x

<REST API 설계 규칙>
1. 슬래시(/)는 계층 관계를 나타낸다.
2. URI의 마지막은 슬래시를 포함하지 않는다.
3. 하이픈은 가독성을 높인다.
4. 언더바(_)는 URI에 사용하지 않는다.
5. URI 경로는 소문자가 적합하다.
6. 파일 확장자는 URI에 포함하지 않는다.

[HTTP 메서드]
<CRUD>
Create-Read-Update-Delete

<HTTP>
GET : 리소스 조회
POST : 요청 데이터 처리(ex.등록)
PUT : 리소스 전체 변경, 해당 리소스 없으면 생성
PATCH : 리소스 부분 변경
DELETE : 리소스 삭제
105 changes: 105 additions & 0 deletions src/mission/chapter6
Original file line number Diff line number Diff line change
@@ -0,0 +1,105 @@
[홈화면]
<API Endpoint>
GET /users/{userId}/home

<Request Body>
없음

<Request Header>
Authorization : accessToken

<query String>
없음


[마이 페이지]
<API Endpoint>
GET /users/{userId}/mypage

<Request Body>
없음

<Request Header>
Authorization : accessToken

<query String>
없음


[리뷰 작성]
<API Endpoint>
POST /users/{userId}/reviews/{reviewId}

<Request Body>
{
“score” : 5,
“content” : “리뷰내용”,
“imageUrl” : “”
}

<Request Header>
Authorization : accessToken

<query String>
없음


[미션 목록 조회(진행중, 진행 완료)]
<API Endpoint>
GET /users/{userId}/missions

<Request Body>
없음

<Request Header>
Authorization : accessToken

<query String>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

query String 쓸 수 있는지는 생각도 못했는데 좋은 접근인 것 같습니다!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

구분 지어서 조회할떄 활용할수 있군요!

진행중 : ?status=ing
진행 완료: ?status=complete


[미션 성공 누르기]
<API Endpoint>
POST /users/{userId}/missions/{missionId}

<Request Body>
{
“status” : “complete”
}

<Request Header>
Authorization : accessToken

<query String>
없음


[회원 가입 하기]
<API Endpoint>
POST /users/sign-up

<Request Body>
{
“name” : “umc”,
“gender” : “선택안함”,
“birth” : “2024-05-22”,
“address” : “서울시..”,
“favorite” : [
{
“name” : “한식”
},
{
“name” : “일식”
},
{
“name” : “양식”
}
]
}

<Request Header>
없음

<query String>
없음