RESTful API는 HTTP 기반의 웹 서비스 설계 패러다임으로, 자원을 중심으로 데이터를 주고받는 현대 웹 및 모바일 애플리케이션의 핵심 통신 방식입니다.
많은 개발자들이 API를 “그냥 HTTP로 만들어진 것”이라고 생각하지만, REST의 개념과 원칙을 제대로 이해하고 설계하면, 시스템의 확장성, 유지보수성, 보안성이 크게 향상됩니다.
이 글에서는 RESTful API의 기본 개념부터 설계 방법까지 자세히 다루어, 지금까지 잘못 만든 API를 개선하고자 하는 분들께 도움이 되고자 합니다.RESTful API는 현대 웹 및 모바일 애플리케이션의 핵심 통신 방식입니다. 많은 개발자들이 API를 “그냥 HTTP로 만들어진 것”이라고 생각하지만, REST의 개념과 원칙을 제대로 이해하고 설계하면, 시스템의 확장성, 유지보수성, 보안성이 크게 향상됩니다. 이 글에서는 RESTful API의 기본 개념부터 설계 방법까지 자세히 다루어, 지금까지 잘못 만든 API를 개선하고자 하는 분들께 도움이 되고자 합니다.


🔍 RESTful API란?

1. 개념 정의

  • *REST(Representational State Transfer)
    *
    REST는 웹의 아키텍처 스타일 중 하나로, HTTP의 기본 메커니즘(메서드, 상태 코드, 헤더 등)을 활용하여 자원을 표현(Representation)하고 상태를 전이(State Transfer)하는 방법입니다.
  • 자원(Resource) : API가 다루는 대상, 데이터의 단위(예: 사용자, 상품, 주문 등)는 고유한 URI를 통해 식별됩니다.
  • 표현(Representation) : 자원의 상태는 JSON, XML 등으로 표현됩니다.

2. REST의 6가지 제약 조건

RESTful API를 설계할 때 지켜야 하는 핵심 제약 조건은 다음과 같습니다:

  1. 클라이언트-서버 :
    클라이언트와 서버의 역할을 명확히 분리하여, 클라이언트는 UI/UX에, 서버는 데이터와 비즈니스 로직에 집중합니다.
  2. 무상태(Stateless) :
    각 요청은 독립적이어야 하며, 서버는 이전 요청의 상태를 저장하지 않습니다. 필요한 모든 정보는 요청에 포함되어야 합니다.
  3. 캐시 가능(Cacheable) :
    응답은 캐시 가능해야 하며, 적절한 캐시 헤더를 통해 성능을 최적화할 수 있습니다.
  4. 일관된 인터페이스(Uniform Interface) :
    API의 모든 상호작용은 일관된 방식으로 진행되어야 합니다. 이를 위해 URI는 명사 형태, HTTP 메서드(GET, POST, PUT, DELETE)를 사용합니다.
  5. 계층화 시스템(Layered System) :
    클라이언트는 서버의 내부 구현(프록시, 게이트웨이 등)을 알 필요 없이 API와 상호작용할 수 있어야 합니다.
  6. 코드 온디맨드(Code on Demand) – 선택 사항 :
    서버가 클라이언트에 실행 가능한 코드를 전송할 수 있으나, 일반적으로는 사용하지 않습니다.

🔍 RESTful API 설계 방법 및 규칙

1. ⭐ 자원 중심 설계 (Resource-Oriented Design) ⭐

  • URI 설계 : 자원을 식별하는 URI는 명사 형태로 구성합니다.
    • 예) /users (전체 사용자), /users/{userId} (특정 사용자)
  • CRUD 작업: HTTP 메서드를 사용해 자원에 대한 작업을 표현합니다.
    • GET /users : 사용자 조회
    • POST /users : 사용자 생성
    • PUT /users/{userId} : 사용자 전체 업데이트
    • PATCH /users/{userId} : 사용자 일부 업데이트
    • DELETE /users/{userId} : 사용자 삭제

2. ⭐ HTTP 메소드 사용 용도 ⭐

HTTP
메서드
용도 설명 멱등성
(Idempotence)
GET 조회 리소스(데이터)를 조회하여 클라이언트에게 반환합니다.
요청 시 서버의 상태를 변경하지 않습니다.
보장
POST 생성 새로운 리소스를 생성할 때 사용합니다.
요청 본문에 생성할 데이터(페이로드)를 포함시킵니다.
보장되지 않음
PUT 전체 수정 기존 리소스를 완전히 대체하여 업데이트합니다.
전체 리소스 데이터를 제공해야 하며, 요청을 여러 번 보내도 동일한 결과가 나옵니다.
보장
PATCH 부분 수정 기존 리소스의 일부 속성만 수정합니다.
전체 리소스를 대체하지 않고, 필요한 부분만 업데이트할 때 사용합니다.
보장되지 않음
DELETE 삭제 지정된 리소스를 삭제합니다.
삭제 작업은 리소스를 완전히 제거하는 작업입니다.
보장

3. ⭐ HTTP 상태 코드 활용 ⭐

  • 200 OK : 요청 성공 (데이터 반환)
  • 201 Created : 새로운 자원 생성 성공
  • 204 No Content : 삭제나 업데이트 성공, 응답 본문 없음
  • 400 Bad Request : 클라이언트 요청 오류
  • 401 Unauthorized/403 Forbidden : 인증/권한 문제
  • 404 Not Found : 자원 미발견
  • 500 Internal Server Error : 서버 오류

4. 📌 데이터 포맷 및 버전 관리

  • 데이터 포맷 : 주로 JSON을 사용합니다.
  • API 버전 관리 : URI에 버전 정보를 포함하거나, 헤더를 통해 버전을 관리합니다.
    • 예: /v1/users 또는 Accept: application/vnd.example.v1+json

5. 🔒 보안 고려사항

  • 인증 및 인가 : JWT, OAuth 등 보안 토큰을 사용해 접근을 제어합니다.
  • HTTPS : 모든 통신은 HTTPS를 통해 암호화하여 안전하게 전송합니다.

6. 📝 문서화

  • Swagger/OpenAPI : API 문서를 자동으로 생성하고, 협업 및 외부 개발자와 공유합니다.
  • Postman Collection : 테스트 및 문서화 도구로 활용하여 API 사용법을 쉽게 전달할 수 있습니다.

🔍 RESTful API 설계 예시

예시 : 사용자 관리 API

GET /v1/users
  - 설명 : 모든 사용자 목록 조회
  - 응답 예시: 
    [
      { "id": 1, "name": "Alice", "email": "alice@example.com" },
      { "id": 2, "name": "Bob", "email": "bob@example.com" }
    ]

GET /v1/users/1
  - 설명: ID가 1인 사용자 조회
  - 응답 예시: 
    { "id": 1, "name": "Alice", "email": "alice@example.com" }

POST /v1/users
  - 설명: 새로운 사용자 생성
  - 요청 예시:
    {
      "name": "Charlie",
      "email": "charlie@example.com"
    }
  - 응답: 201 Created, Location 헤더에 새 리소스 URI 포함

PUT /v1/users/1
  - 설명: ID가 1인 사용자의 전체 정보 업데이트
  - 요청 예시:
    {
      "name": "Alice Smith",
      "email": "alice.smith@example.com"
    }
  - 응답: 200 OK

DELETE /v1/users/1
  - 설명: ID가 1인 사용자 삭제
  - 응답: 204 No Content

⚡ RESTful API 설계의 핵심 포인트

  • 자원 중심: 모든 API는 자원(데이터) 관점에서 설계
  • HTTP 메서드 활용: GET, POST, PUT/PATCH, DELETE로 CRUD 구현
  • 상태 코드 및 에러 처리: 클라이언트와 서버 간의 명확한 의사소통
  • 보안과 버전 관리: HTTPS, 인증, 버전 관리로 신뢰성 확보
  • 문서화: Swagger 같은 도구를 활용해 명확한 API 문서 제공

⚡ RESTful API 설계 시 유의사항

  • 일관성 유지 : API 전반에 걸쳐 일관된 URI 구조, 메서드 사용, 상태 코드 활용.
  • 확장성 고려 : 미래에 자원이 늘어나거나, 기능이 확장될 때에도 쉽게 관리할 수 있도록 설계.
  • 에러 핸들링 : 명확한 에러 메시지와 상태 코드를 제공해 클라이언트가 문제를 쉽게 파악할 수 있도록 합니다.
  • 보안 강화 : 인증, 인가, HTTPS 적용 등 보안 측면을 항상 최우선으로 고려.
  • 문서화 필수 : 잘 작성된 API 문서는 개발자와 사용자가 API를 쉽게 이해하고 활용할 수 있도록 돕습니다.

💡 결론

RESTful API는 자원 중심의 인터페이스로 설계함으로써, HTTP의 기본 원칙을 활용해 확장성과 유지보수성, 협업 효율성이 뛰어난 시스템을 만들 수 있습니다.
올바른 URI 설계, HTTP 메서드의 적절한 활용, 명확한 에러 처리 및 보안 강화를 통해 API의 일관성과 신뢰성을 높일 수 있으며, Swagger 같은 도구를 활용해 문서화를 철저히 하는 것이 성공적인 RESTful API 설계의 핵심입니다.

728x90
반응형

ASP 세션 객체

컴퓨터에서 어플리케이션으로 작업할 때 어플리케이션을 열고 일부 변경한 다음 닫음.
이건 세션와 유사한데, 컴푸터는 작업자가 누군지 알고있고, 어플리케이션을 열 때와 닫을 때를 알고 있음.
그러나 인터넷에는 한 가지 문제점이 있는데, HTTP 주소는 상태 유지를 지원하지 않기 때문에 웹서버는 당신이 누구이고, 무엇을 하는지 모름.

ASP는 각 사용자에 대해 고유 쿠키를 만들어 이 문제를 해결함. 쿠키는 컴퓨터로 전송되며 사용자를 식별하는 정보가 포함됨.
이 인터페이스를 Session 객체라고 함.

Session 객체는 사용자 세션에 대한 정보를 저장하거나 설정을 변경함.

Sessio 객체에 저장된 변수는 단일 사용자에 대한 정보를 보유하며, 하나의 어플리케이션의 모든 페이지에서 사용할 수 있음. 세션 변수에 저장되는 공통 정보는 이름, ID 및 기본 설정등임. 서버는 각각의 새 사용자에 대해 새 Session 객체를 만들고, 세션이 만료되면 session 객체를 삭제함.

 


세션의 시작

  • 새 사용자가 ASP 파일을 요청하고 Global.asa 파일에는 Session_OnStart 프로시져가 포함됨.
  • 값은 세션 변수에 저장됨.
  • 사용자가 ASP 파일을 요청하고 Global.asa 파일은 <object> 태그를 사용하여 세션 범위의 개체를 인스턴스화 함.

세션의 종료

사용자가 지정된 기간 (기본 시간은 20분) 동안 어플리케이션에서 페이지를 요청하거나 새로 고치치 않으면 세션은 종료됨.

기본보다 짧거나 긴 시간 초과 간격을 사용하려면 Timeout 속성을 사용해야 함.

  //  세션 유지 시간을 5분으로 설정함.
  Session.Timeout = 5

Abandon 메소드를 사용하여 세션을 즉시 종료함.

  Session.Abondon

세션의 주요 문제는 세션을 종료해야하는 시간임. 사용자의 마지막 요청이 마지막 요청인지 아닌지 알 수 없음. 따라서 세션을 "활성" 상태로 유지해야하는 기간을 알 수 없음. 유휴 세션을 너무 오래 기다리면 서버의 리소스가 소모되지만 세션이 너무 빨리 삭제되면 서버가 모든 정보를 삭제했기 때문에 사용자가 처음부터 다시 시작해야 할 수 있음. 적절한 세션초과 시간을 찾는 것은 어려움.
세션 변수에 데이터를 너무 많이 저장해 둬도 좋지 않음.

 

 


세션 변수 저장 및 검색

세션 객체에서 가장 중요한 것은 변수를 저장할수 있다는 것임.

  <%
    session( "username" ) = "borry"
    seesion( "age" ) = 3
  %>

값이 세션 변수에 저장되면 ASP 어플리케이션의 모든 페이지에서 이 값에 도달할 수 있음.

Welcome <%response.write( session( "username" ) ) %>

세션 객체에 사용자 기본 설정을 저장한 다음 해당 기본 설정에서 엑세스하여 사용자에게 반환할 페이지를 선택할 수도 있음.

  <%IF session( "screenres" ) = "low" THEN%>
    This is the text version of the page
  <%ELSE%>
    This is the multimedia version of the page
  <%END IF%>

 

세션 변수 제거

Contents 컬렉션에는 모든 세션 변수가 포함됨.
remove 메소드를 사용하면 세션 변수를 제거할 수 있음.
"age"값이 18보다 작은 경우 세션 변수 "sale"을 제거함

  <%
    session.( "sale" ) = true

    if session.contents( "age" ) < 18 then
      session.contents.remove( "sale" )
    end if
  %>

세션의 모든 변수를 제거하려면 removeAll 메소드를 사용함.

  session.contents.removeAll()

 

 


컨텐츠 컬렉션을 통해 반복문

contents collection에 모든 세션 변수가 포함됨. contents collection을 반복하여 컬렉션에 무엇이 저장되어 있는지 확인 가능함.

  session( "username" ) = "borry"
  session( "age" ) = 3

  dim i
  for each i in session.contents
    response.write( i & "<br/>" )
  next

contents collection의 항목 수를 모르는 경우 count 속성을 사용할 수 있음.

  <%
    dim i, j
    j = session.contents.count
    response.write( "session variables : " & j )

    for i = 1, to j
      response.write( session.contents( i ) & "<br/>" )
    next
  %>

 

StaticObjects Collection을 통한 반복문

StaticObjects Collection을 반복하여 session 객체에 저장된 모든 개체의 값을 볼 수 있음. 나는 이 코드가 작동 안 하는데 원인은 모르겠다.

  <%
    dim k
    for each k in session.staticObjects
      response.write( k & "<br/>" )
    next
  %>

728x90
반응형

'WEB > ASP' 카테고리의 다른 글

[ASP] #include  (0) 2021.08.27
[ASP] 어플리케이션  (0) 2021.08.27
[ASP] 쿠키  (0) 2021.08.26
[ASP] form  (0) 2021.08.26
[ASP] 반복문  (0) 2021.08.26

+ Recent posts