URL Rules

• 마지막에 / 포함하지 않는다.

• _(underbar) 대신 -(dash)를 사용한다.

• 소문자를 사용한다.

• 행위(method)는 URL에 포함하지 않는다.

• 컨트롤 자원을 의미하는 URL은 예외적으로 동사를 허용한다.

  • 함수처럼, 컨트롤 리소스를 나타내는 URL은 동작을 포함하는 이름을 짓는다.

  <http://api.test.com/posts/duplicate>
  

Use HTTP methods

• 보안을 위해서는 GET방식도 되도록 POST방식으로 요청하는게 좋다.

  역할

REST API 설계 기본 규칙

• URI는 정보의 자원을 표현해야 한다.
  • resource는 동사보다는 명사를, 대문자보다는 소문자를 사용한다.
  • resource의 도큐먼트 이름으로는 단수 명사를 사용해야 한다.
  • resource의 컬렉션 이름으로는 복수 명사를 사용해야 한다.
  • resource의 스토어 이름으로는 복수 명사를 사용해야 한다. Ex) GET /Member/1 -> GET /members/1
• 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.
  • URI에 HTTP Method가 들어가면 안된다. Ex) GET /members/delete/1 -> DELETE /members/1
  • URI에 행위에 대한 동사 표현이 들어가면 안된다.(즉, CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.) Ex) GET /members/show/1 -> GET /members/1 Ex) GET /members/insert/2 -> POST /members/
  • 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.(즉, :id는 하나의 특정 resource를 나타내는 고유값이다.) Ex) student를 생성하는 route: POST /students Ex) id=12인 student를 삭제하는 route: DELETE /students/12

Use the correct HTTP status code.

• 성공 응답은 2XX로 응답한다.

  • 로그인이 실패되도 200으로주고 status는 FAIL과 에러메세지를 반환한다.

  • error메세지에는 error코드와 에러메세지두 가지 형식으로 준다.

  • error코드는 어떤 코드 상태인지 보기 위해서 에러 메세지는 클라이언트가 문구를 작성하지않고 서버에서 바로 보여줄 수 있다면 가장 좋다.

    {
    status:200
     "errors": [
      {
        "code": "701",
        "msg": "아이디 혹은 비밀번호를 확인하세요."
      }
     ]
    }
    

• 실패 응답은 4XX로 응답한다.

• 5XX은 서버(apache, nginx)가 오류일 때는 서비스 장애임으로 사용은 가능하나 REST API는 에러에 대한 핸들링이 가능해야함으로 사용자에게 나타나지 말 것.

Paging

• Paging Key
  • 페이징의 경우 데이터 검색된 전체 데이터수를 반환하게 한다.

응답형태는 KEY가 동일한 포맷으로 한다.

{
    "status" : "SUCCESS",
    "code": 200,
    "message": null,
    "page": {
                "countPerPage": 10, // 총 페이지
                "totalCount": 100, // 총 데이터 갯수
                "currentPage": 1//현재 리턴한 페이지 페이지
            },
    "data": [{
		    userName:
     }]//여러개일 때
    "data": {}//하나의 데이터 일때
}

그 외의 팁