🩵 URL
URL은 웹 상에 존재하는 자원의 위치를 가리키는 주소입니다.
자원은 문서, 이미지, 동영상 등 어떤 것이든 될 수 있어요.
URL은 특정 자원에 대한 요청을 식별하고 전달하는 데 사용됩니다.
- Protocol 프로토콜
- Domain 도메인
- Port 포트번호
- Path 경로
- Query Parameters 쿼리 매개변수
URL은 해당 5가지로 구성이 되어 있습니다.
✔️ 프로토콜
- http : 보안 없는 통신
- https : 보안된 통신 (SSL / TLS 암호화 사용)
프로토콜은 클라이언트와 서버 간의 통신 방법(규칙)을 지정합니다.
✔️ 도메인
도메인은 API 서버가 호스팅되는 서버의 주소입니다.
API 서버가 위치한 서버의 주소를 도메인으로 나타낸다는 것을 의미합니다.
도메인은 일반적으로 서버의 IP 주소를 사람이 이해하기 쉬운 형태로 변환하여 사용됩니다.
API 서버는 특정한 주소(IP 주소)에서 동작하는데, 이 주소를 사람이 이해하기 쉬운 형태로 나타낸 것이 도메인입니다.
사용자가 서버에 연결하거나 특정 리소스에 액세스할 때 사용됩니다.
위의 예시처럼 하단 형태의 도메인을 사용하면
DNS(Domain Name System)을 통해 실제 IP 주소로 해석되어 통신이 이루어집니다.
api.example.com
- 사용자가 IP 주소를 직접 기억할 필요가 없고
- 도메인 이름을 통해 쉽게 서버에 엑세스할 수 있습니다
✔️ 포트
포트는 웹 서버에 접속해서 API 요청을 수신하는데 사용되는 번호입니다.
따로 지정해주지 않으면 기본적으로 사용되는 포트 번호가 있습니다.
- http : 80
- https : 443
포트는 서버에서 여러 서비스가 동시에 동작할 수 있도록 구별하는 역할을 합니다.
서버에는 여러 포트가 열려 있을 수 있고, 각 포트는 다른 서비스와 연관되어 있습니다.
✔️ 경로
서버에서 제공하는 자원이나 서비스의 위치를 나타냅니다.
URL 경로는 도메인 다음에 위치하며 슬래시("/")로 구분됩니다.
URL 경로는 요청된 자원이나 서비스를 정확하게 식별하는 데 중요한 역할을 합니다.
예시 1)
제 블로그 관리자 화면의 URL 앞부분입니다. 이걸 예시로 도메인과 경로를 나누어 볼게요.
- yy-dev.tistory.com : 도메인 (서버의 주소)
- /manage : 경로 1 (서비스의 위치)
- /newpost : 경로 2
- /manage : 경로 1 (서비스의 위치)
이렇듯 경로는 계층적인 구조를 가집니다.
/manage/newpost 라는 경로는 관리자 화면에서 새로운 포스팅을 작성하는 부분을 나타내는 경로가 됩니다.
예시2)
https://example.com/blog/post/123
해당 URL에서 경로는 /blog/post/123 입니다
블로그의 post 중 ID가 123인 게시글을 나타내는 경로이죠.
이런 부분은 서버의 디렉토리 구조와도 연관됩니다.
(?로 시작되는 type 부터는 쿼리 매개변수에 관련된 내용입니다)
URL만 잘 파악해도 단순한 계층 구조는 알 수 있습니다.
사실 이 부분은 웹 개발을 하시는 분이면 그냥 몰라도 자연스레 체득을 하는 부분 같습니다.
더 자세히 알고 싶다면 웹 개발을 가볍게 공부해 보시는 것도..?
✔️ 쿼리 매개변수
쿼리 매개변수는 URL에 추가 정보를 전달하는데 사용되는 특별한 매개변수입니다.
일반적으로 URL의 끝에 ?로 시작하며, 각각의 쿼리 매개변수는 key=value 형식으로 구성되며 &로 구분됩니다.
- ? 이후에 나오는 것 : 첫 번째 쿼리 매개변수
- type=post : "type"은 쿼리의 키(key) 이고 "post"는 해당 키의 값(key value) 입니다. (REST API에 관련된 내용입니다)
- &를 사용하여 다른 쿼리 매개변수를 추가할 수 있습니다.
- returnURL=%2Fmanage%2Fposts%2F: "returnURL" 키의 값은 "%2Fmanage%2Fposts%2F" 입니다.
- %2Fmanage%2Fposts%2F
- URL 인코딩 되어있습니다.
- 여기서 %2F는 URL 인코딩된 슬래시("/")를 나타냅니다. 디코딩하면 "/manage/posts/"가 됩니다.
따라서, 이 URL은 "type"이 "post"이고 "returnURL"이 "/manage/posts/"인 쿼리 매개변수를 가진 것으로 해석할 수 있습니다.
🩵 REST API
REST는 클라이언트와 서버 간의 효율적인 통신을 위해 HTTP 프로토콜을 기반으로 하는 규칙입니다.
RESTful API는 이러한 원칙을 따라 클라이언트와 서버 간의 일관된 규칙을 유지하며,
HTTP 메소드(GET, POST, PUT, DELETE 등)를 활용하여 리소스의 표현을 전달하고 상태를 전송합니다.
이를 통해 간결하면서도 효과적인 통신이 가능하며, 클라이언트와 서버 간의 상호작용을 일관성 있게 제공합니다.
✔️ HTTP Methods
GET | 리소스를 조회하기 위해 사용되며, 서버에서 데이터를 가져옵니다. | 사용자 조회 |
POST | 새로운 리소스를 생성하기 위해 사용되며, 서버에 데이터를 전송합니다. |
|
PUT | 기존 리소스를 업데이트하기 위해 사용되며, 전체 리소스를 업데이트합니다. |
|
DELETE | 리소스를 삭제하기 위해 사용되며, 서버에서 해당 리소스를 제거합니다. | 사용자 탈퇴(삭제) |
✔️ 자원 Resources
REST API에서는 모든 데이터가 자원으로 표현됩니다.
이러한 자원은 일반적으로 URI로 표현되는 고유한 식별자를 갖고 있습니다.
(웹 사이트의 사용자 프로필, 글, 이미지, 동영상 등이 이에 해당)
✔️ URI (Uniform Resource Identifier)
URI는 해당 자원을 찾을 수 있는 주소를 나타내며, 자원은 URI를 통해 식별됩니다.
웹 사이트의 사용자 프로필을 나타내는 URI는 https://example.com/users/123과 같이 표현될 수 있습니다.
- example.com -> 도메인
- /users/123 -> 경로
💡 URL과 URI의 차이
- URI는 리소스를 식별하기 위한 일반적인 용어
- URL은 리소스의 위치를 나타내는 구체적인 형태의 URI
✔️ 표현 Representations
자원의 상태는 다양한 형식으로 표현될 수 있습니다.
주로 JSON 형식이 사용되고 있습니다.
- 클라이언트가 서버에게 요청을 보내면
- 서버는 해당 자원의 상태를 JSON 형식으로 응답하여
- 클라이언트가 원하는 데이터를 효과적으로 전달합니다.
이러한 방식은 클라이언트와 서버 간의 일관된 통신을 가능하게 하며, JSON은 이를 위한 표준 형식 중 하나로 널리 사용됩니다.
✔️ 연결 Stateless Communication
REST API는 클라이언트와 서버 간의 통신을 위한 연결을 유지하지 않습니다.
각 요청은 독립적으로 처리되며, 상태 정보가 서버에 저장되지 않는 stateless 특성을 가집니다.
이런 특징은 서버가 각 요청을 개별적으로 이해하고 처리할 수 있도록 합니다.
확장성 (Scalability) | 상태를 유지하지 않으면 서버는 각 요청을 개별적으로 이해하고 처리할 수 있습니다. 각 요청이 독립적으로 처리되므로 하나의 요청이 실패해도 다른 요청에는 영향을 주지 않습니다. 이는 서버의 안정성을 향상시키고, 장애 복구가 더 수월하게 이루어질 수 있도록 합니다. 서버는 클라이언트의 상태를 유지할 필요가 없기 때문에 요청이 증가하더라도 서버는 각각의 요청을 동등하게 처리할 수 있습니다. |
상태 관리의 간소화 | 서버가 클라이언트의 상태를 유지하지 않기 때문에 각 요청이 독립적으로 처리됩니다. 이는 서버가 클라이언트의 세션 정보나 상태를 관리할 필요가 없다는 의미입니다. |
캐싱의 용이성 | Stateless한 특성은 응답이 캐시될 수 있음을 의미합니다. 클라이언트는 서버의 응답을 캐시하여 이전에 받았던 데이터를 재사용할 수 있습니다. |
이번 글에서는 URL, REST API의 기본 개념 및 특징에 대해 알아보았습니다.
다음 포스팅에서는 Swift에서의 네트워크 통신에 관한 주제를 다룰 것입니다.
URLSession을 활용한 네트워크 요청, 비동기 작업 처리, 그리고 JSON 데이터 디코딩에 대한 공부 내용을 적어볼 예정입니다 🚀
2024.01.04 - [iOS/SWIFT] - [Swift] 네트워크 통신(2) - URLSession(GET)과 Decodable 프로토콜
'iOS > Swift' 카테고리의 다른 글
[Swift] 아키텍처 Architecture(1) - MVC 패턴 (1) | 2024.01.27 |
---|---|
[Swift] 네트워크 통신(2) - URLSession(GET)과 Decodable 프로토콜 (1) | 2024.01.04 |
[Swift] Delegate Pattern에서 AnyObject를 사용하는 이유는? (0) | 2024.01.02 |
[Swift] UIStackView 사용, UILabel.font 속성 연속 사용, @objc 어노테이션 (0) | 2023.12.27 |
[Swift] tableview가 변경되었을 때 처리하는 방법, beginUpdates() endUpdates() (1) | 2023.12.19 |