iOS 캠프 특강 [REST API] 요약

• 2021.03.11 목요일
• 노션 링크
• API 명세 샘플은 추후 Postman에서 사용가능한 JSON파일로 공유할 예정

Rest의 정의

• 과거 XML-RPC 등의 통신 규약의 복잡도등의 문제로 제안된 통신방식/아키텍처
• Representational State Transfer (표현에 의한 상태 전달)
• 자원을 이름으로 구분하여 상태를 주고받는다
• URI와 HTTP 프로토콜을 이용해 자원을 제어한다

Rest 에서 말하는 자원과 표현은 무엇을 의미하는가?

• URI: 자원의 위치, 경로
• Resource: 자원
• Domain: 사람이 쉽게 기억할 수 있도록 IP에 이름을 부여한 것

HTTP 프로토콜의 구조를 알아보자

• Request: 클라이언트에서 서버로 보내는 요청
• Response: 서버에서 클라이언트로 보내는 응답
• Header
• Body
• Method
  • GET: READ
  • POST: Create
  • DELETE: Delete
  • PUT: Update
  • PATCH: Update(Partial)
  • 현실적으로 PUT/PATCH를 확실히 구분해서 사용하는곳이 많지 않다
• Status
  • 200 (OK): 요청성공에 대표적인 코드. 안좋은 서비스에서는 모든 것을 200으로 처리해버린다…
  • 201 (Create): POST/PUT요청이 성공해서 결과로 새로운 리소스가 생성됏을 때
  • 202/203 잘안씀
  • 204 (No Content): 요청이 정상이지만 데이터가 없음. (회원가입 하자마자 주문내역 조회한 한다면 데이터가 없을것임)
  • 205 (Reset Content): 가끔 사용. 캐쉬 기능에서 데이터가 오래됐다면 reset하라고 할 때
  • 300번대: 네이티브 앱에서는 사용할일 없음
  • 400 (Bad Request): 보통 POST/PUT/PATCH 에서 발생. 바디값에 문제 있을 때
  • 401 (Unauthorized): 로그인하면 로그인 상태값을 토큰이나 string데이터로 전달받으며 그 값 들고 서버에 요청해야함. 내 정보를 수정하려하는데 내 상태값이 잘못된 경우
  • 402: 거의 안씀
  • 403 (Forbidden): 401과 비슷. 권한 없는것을 요청할 경우
  • 404 (Not Found): 잘못된 URL, 99.9% 휴먼에러…
  • 405: URI에서 지원하지 않은 메소드를 사용했을 때
  • 406: 400과 비슷
  • 408 (Request Timeout): 요청시간이 너무 오래 걸림
  • 411 (Length Required)
  • 412 (Precondition Failed): 헤더의 내용이 유효하지 않을 때
  • 418: 만우절용 코드인대, 지금은 하위호한 때문에 지워지지 않음
  • 428 (Precondition Required): 헤더값 누락
  • 429 (Too Many Requests): 지정된 시간에 너무 많은 요청
  • 500: 서버가 처리방법을 모르는 상황, 예외처리 안됐을 때
  • 502: 네트워크 문제. IP는 유효한대 서버 죽음

상태코드를 세부적으로 나누기 어렵다면, 중요한 코드만 골라보면

• 200: 대부분 정상요청
• 201 (사용하는게 좋지만 200으로 해도됨)
• 204
• 400: 약속된 명세 어겼을 때 모두 400 처리
• 401: 인증 관련 오류
• 500

Rest의 규칙. 장점과 단점

• 무엇을 REST라고 부르는가
  • HTTP, Stateless, Hateoas
• 장점 (= HTTP의 장점)
  • 기존 HTTP 인프라 그대로 사용 가능
  • 서버와 클라이언트의 역할을 명확히 구분 가능
• 단점
  • 표준이 없다

Rest 맛보기

사용자가 사진을 공유하고 좋아요르르 통해 피드백을 받을 수 있는, 사진첩 서비스의 Rest API를 만들어 보자.

1. 사용자 가입할 때 아이디, 닉네임, 자기소개, 비밀번호를 입력한다
2. 사용자는 로그인을 할 수 있다.
3. 사용자는 본인의 개인정보를 수정할 수 있다.
4. 가입된 사용자 정보를 확인할 수 있다.
5. 사용자 정보를 조회할 경우, (아이디, 닉네임, 자기소개, 가입일)의 데이터를 확인할 수 있다.
6. 사용자가 올린 사진들을 모두 조회할 수 있다
7. 모든 사용자의 사진을 모아볼 수 있다.
8. 사용자는 사진과 간단한 본문 내용을 작성할 수 있다.
9. 사용자는 사진에 좋아요를 통해 관심을 표현할 수 있다.

• 자원을 생성이 성공했으면 성공한 데이터를 볼 수 있어야함
  • 회원가입을 했다면 그 정보에 접근할 url이나 그 정보 자체를 줘야 한다
• DELETE한다고 서버에서 진짜로 데이터를 삭제하는 경우는 없다.
  • 의미없는 데이터로 치환한다거나 다른 방법 사용
• URI 뎁스가 너무 깊어지면 추후 떼어내기 힘들다

POST 예시

• URI: /users
• Request body

// Request Body
{
    "id": "123",
    "name": "123"
}

// Response Body
{
    "userNo": 100,
    "id": "123",
    "name": "123",
    "about": "",
    "createdAt": "2021-03-11T04:41:37.09",
    "links": [ // 내가 이 행위(POST)를 함으로서 다음에 할 행위의 주소를 명시적으로 표현해줌 (규칙 컨벤션 있음)
        {
            "rel": "self", // 나 자신을 조회하는 명세
            "href": "http://api.yagom.com/users/100",
            "method": "GET"
        },
        {
            // 생략...
        },
        
    ]
}

GET 예시

• 페이지를 불러온 경우
• lastPage, hasNext, hasPrev 등으로 페이지 네비게이션 정보가 꼭 필요하다!