API는 프론트와 백이 소통하는 창구라고 생각한다. 그래서 무엇보다도 협업하는 프로젝트를 할때에는 중요하다고 생각했다.토이프로젝트이기 때문에, API 설계를 어떻게 하더라도 프로젝트는 완성이 될 것 이지만, 우리팀은 토이프로젝트라도 하나하나 신경쓰고 공들여서 만든 프로젝트를 만들고 싶었다. 그래서 API설계부터 공을 들이고 싶었다.

URL Rules

• 마지막에 / 포함하지 않는다.
• _ 대신 - 사용
• 소문자를 사용한다
• method(행위)는 URL에 포함하지 않는다.
• 컨트롤 자원을 의미하는 URL 예외적으로 동사를 허용한다.

API 설계할때, 공통 서식이 필요했다.

이전 Response 때는 이런 형식을 사용했는데, 사실상 status가 프로젝트때 크게 필요가 없었다. 우리가 제대로 쓸줄을 몰랐던 걸까...

{
	"status" : ,
	"message" : ,
	"data" : 
}

그래서 이번에는 status로 나누지 않고, 상황별로 code를 만들어서 Error를 날릴까 생각해보았다. kakao에서는 이름으로 했던데, 그렇게 하면 오타가 났을때, 힘들것 같다고 했던 부분에 대해서는 이해가된다.

{
	"code" : ,
	"message" : ,
	"data" : 
}