Keyword & overview
//요청메시지
GET https://example.org/greeting
Host: example.org
Accept: text/plain, text/html; q=0.9 *; q=0.1
Accept-Language: en, ko; q=0.9, *; q=0.1
//응답메시지
HTTP/1.1 200 OK
Content-Length: 6
Date: Sun, 19 Mar 2017 10:20:47 GMT
Last-Modified: Sun, 19 Mar 2017 08:00:00 GMT
Content-Type: text/plain
Content-Language: en
hello World // body(본문)
"Content-Type: text/plain"
와 같은 → representation metadata'Accept-Language: ko'
과 같 헤더를 포함시켜 GET요청을 보낸다면, 서버가 한국어로 된 적절한 representation data를 응답으로 전송주의) state라는 동일한 단어로 표현하지만, 웹앱의 상태와 리소스의 상태는 다름. 웹앱 상태는 페이지A를 렌더링하다가 B를 렌더링하는 것으로 바뀐 그 상태
URI vs URL
-URI(uniform resource identifier)는 네트워크 상 리소스의 위치를 알려주기 위한 규약? *인터넷 프로토콜 관련
-URL(uniform resource locator)는 인터넷에 있는 리소스의 유일한 주소? URI가 상위 개념, URL이 포함된다고 보면 됨
- 좋은 예인지는 모르겠지만:
https://example.com/one?id=123 의 경우 URL은 https://example.com/one 까지이고, 내가 원하는 정보에 도달하기 위해서는?id=123
이라는 식별자가 필요한 것. 이 또한 URI이지만 URL은 아닌것.
🤔 고민해볼 주제들..
- What are the best practices: args in query string vs in request body vs url path
- In the request body - As part of a json body, or other MIME type
- In the query string - e.g.
/api/resource?p1=v1&p2=v2
- As part of the URL-path - e.g.
/api/resource/v1/v2
⇒ Path Variable과 Query Parameter를 각각 언제 사용해야 하는가?
만약 어떤 resource를 식별하고 싶으면 Path Variable을 사용하고, // (a)
정렬이나 필터링을 한다면 Query Parameter를 사용하는 것이 Best Practice이다. // (b)
/users # 사용자 목록을 가져온다.
/users?occupation=programer # 프로그래머인 사용자 목록을 가져온다. // (b)
/users/123 # 아이디가 123인 사용자를 가져온다. // (a)
*기본적인 CRUD 기능을 위해서, 또 다른 URL이나 query parameter를 정의할 필요는 없음! 대신 원하는 기능에 맞게 HTTP 메소드를 바꾸어 사용하면 됨!
/users [GET] # 사용자 목록을 가져온다.
/users [POST] # 새로운 사용자를 생성한다.
/users/123 [PUT] # 사용자를 갱신한다.
/users/123 [DELETE] # 사용자를 삭제한다.
거의 모든 CRUD 프로세스를 추가적인 endpoint(예를 들어 users/create
) 또는 query parameter(예를 들어 users?action=create
) 없이 수행할 수 있는 것임. 메서드의 구분으로 단순화되고, 예측이 가능하다.
본문
Representational State Transfer 🔗 Wikipedia
www 개발 및 설계를 위한 소프트웨어 아키텍처이다.
웹과 같은 Internet-scale distributed hypermedia system의 아키텍처가 어떻게 (behave)해야하는지 제약조건들의 모음이다.
REST원리를 따르는 시스템을 RESTful하다고 말한다.
When these constraints are applied to the system architecture, it gains desirable non-functional properties, such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability. A system that complies with some or all of these constraints is loosely referred to as RESTful
: 클라이언트는 URI를 통해서만 리소스에 접근이 가능함.
클라이언트는 URI 를 가지고 요청을 보내고, 서버는 리소스의 표현데이터를 응답으로 전송
REST API 구조는 인터넷계층에서 사용할 수 있도록 설계 되었으므로, 클라이언트-서버 간 결합이 경량(loose)이어야 함. → 대규모 채택이 용이하도록. 이는 엔티티를 캡슐화하여 리소스를 정의함으로써 서버측에 추상화된 계층을 형성함으로써 가능한 것.
[원문]
it is designed for Internet-scale usage, so the coupling between the user agent (client) and the origin server must be as lightweight (loose) as possible to facilitate large-scale adoption. This is achieved by creating a layer of abstraction on the server by defining resources that encapsulate entities (e.g. files) on the server and so hiding the underlying implementation details (file server, database, etc.).
...중략
Clients can only access resources using URIs. In other words, the client requests a resource using a URI and the server responds with a representation of the resource. Thus, a resource is manipulated through hypertext representations transferred in messages between the clients and servers.
...후략
: REST(아키텍처)원리의 조건을 따르는 API
-A REST API (RESTful API) is an application programming interface (API or web API) that conforms to(adheres to) the constraints of REST architectural style and allows for interaction with RESTful web services
-Web service APIs that adhere to the REST architectural constraints are called RESTful APIs
클라이언트에서 RESTful API를 통해 요청을 보내면, requester나 엔드포인트로 리소스의 (현재)state에 대한 표현데이터를 전송(transfer)함
이 표현데이터라는 정보는 http를 통해 여러 포맷 중 하나로 전달됨(JSON/ HTML 등등) -JSON이 자연어와 기계어 모두 readable하므로 흔히 쓰임
🌟 RESTful 하게 API를 작성한다는 것 🌟
: RESTful한 api 란
- 클라이언트-서버 구조(클라이언트, 서버, 리소스로 구성된)에서, http를 통해 요청 및 응답 전송
- '무상태성 Stateless' 서버에 클라이언트 상의 정보 state가 저장되면 안되며, 각 요청은 독립적임
- 클라이언트가 응답을 캐싱할 수 있어야 함
- 컴포넌트 간 일관된 인터페이스. 정보가 일관된 형식으로 전송되어야 함
- 요청된 리소스는 개별적으로 식별가능해야 하며, 클라이언트에 전달된 표현데이터와 분리되어야 함
- 표현데이터만으로도 클라이언트 상에서 리소스를 조작가능하다. 표현데이터가 리소스를 다루는 정보를 충분히 포함하고 있음.
- 서버의 계층구조는 클라이언트 측에서 알 수 없음.
🔗 원문
http://api.example.com/
;[Http method]
: [description]