목차
1.
4.
1. URL 규칙
•
URL 마지막에 /를 포함하지 않는다.
•
URL 경로에서는 소문자를 사용한다.
•
가능하면 명사를 사용한다. 명사는 복수형태로 사용한다(일부 약어 제외).
•
컨트롤 자원의 경우 예외적으로 단수 명사를 사용 가능하다.
•
가능하면 한단어로 구성하여 사용한다. 두 단어 이상으로 사용할 경우 - 를 이용한다.
•
행위는 URL이 아닌 method로 사용한다.
활용해보시고 자유롭게 예제를 추가해 주세요
ex) 회원가입
http://api.com/users/signup
ex) 유저 수정과 별개로 유저를 할당 해야할 경우
http://api.com/users/assignment
ex) 유저 중복 아이디 체크
http://api.com/users/duplication
Plain Text
복사
2. method 활용 규칙
•
각각의 메서드는 API 목적에 맞게 사용되어야 한다.
•
get: 클라이언트에서 데이터를 요청할 때 사용되며, 데이터를 변경시키지 않아야 한다.
•
post: 데이터 베이스에 데이터를 생성하도록 요청한다.
•
put: 전체 데이터를 수정, 혹은 데이터가 존재하지 않을 경우 생성하도록 요청한다.
•
patch: 데이터의 일부분을 수정하도록 요청한다.
•
delete: 데이터를 제거하도록 요청한다.
•
API는 각각의 메소드 및 API 역할에 맞는 상태코드를 보내야 한다.
status code | 200 | 201 | 202 | 204 | 400 | 401 | 403 | 404 | 500 |
get | vv | v | v | v | v | v | |||
post | v | vv | v | v | v | v | v | ||
put | v | v | v | v | v | v | v | v | v |
patch | vv | v | v | v | v | v | v | ||
delete | vv | v | v | v | v | v | v |
3. Parameters 규칙
•
경로 파라미터
◦
URL 경로 추가 시, 경로 데이터의 위치를 나타내도록 사용해야 한다.
◦
get 요청(단일 데이터 지정) put, patch 요청(수정할 데이터 지정) delete 요청(삭제할 데이터 지정) 시 주로 사용한다.
users(No. 1)가 쓴 comments(No. 113)를 삭제할 경우
https://api.com/comments/113 (o) (113이 comments의 주소를 나타냄으로 선호되는 방식)
https://api.com/comments/1 (x)
(만약에 유저당 1개의 comments를 달 수 있어 comments 당 user No. 가 unique 하더라도
comments 경로의 데이터 위치를 설명하지 못하여 선호되지 않는 방식)
Plain Text
복사
•
쿼리 파라미터
◦
민감한 데이터는 HEADER로 전달해야 한다.
◦
get 요청에서만 활용하고 다른 요청에서 사용하지 말아야 한다.
•
Body
◦
post, patch 에서 활용된다.
◦
원칙상 delete 에서는 사용하지 않도록 한다.
•
파라미터 공통
◦
요청 파라미터의 경우 카멜 케이스를 사용한다.
4. 기타
•
Header
◦
Content-Type:application/json(대부분 API가 json 형식으로 보냄)
◦
Authorization: Bearer {token}
•
