RESTful API

camille·2022년 5월 29일

📕 RESTfulAPI라는 것은?

API 시스템을 구현하기 위한 아키텍처 중에 가장 널리 사용되는 형식이다.

Graphql,SOAP,GRPC,REST...etc

📕 Representational State Transfer

웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고 그 리소스에 대한 행위를 HTTP Method로 정의 하는 방식. 즉 리소스(HTTP URI로 정의된)를 어떻게 한다.(HTTP Method + Payloda)를 구조적으로 깔끔하게 표현한다.

왜 restfulAPI를 많이 사용하는가?

코드의 복잡성이 올라가면서 직관적인 코드가 필요시 되기때문에 JSON을 사용한다.

💡 기본적인 배경지식
URI(Uniform Resource Identifier)

해당사이트의 특정 자원의 위치를 나타내는 유일한 주소

HTTP Method

HTTP request가 의도하는 action을 정의한 것

Payload

HTTP request에서 server로 보내는 데이터(body)

📕 RestfulAPI 설계규칙

URI 정보를 명확하게 표현해야한다.
: resource는 명사를 사용하야 한다.
ex) GET/user/1 -> GET/users/1
resource에 대한 행위를 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
: URI에 HTTP Method가 포함되서는 안된다.
ex) GET delete/user/1 -> DELETE/users/1

:URI에 동사가 포함되서는 안된다.
ex) GET/user/show/1 -> GET/users/1
ex) POST insert/users/2 -> POST/users/2
resource 사이에 연관 관계가 있는 경우
: /리소스/고유ID/관계 있는 리소스
ex)GET/users/{user_id}/profile
파일의 경우 payload의 포멧을 나타내기 위한 파일 확장자를 URI에 포함시키지 않는다.
ex) GET user/1/profile-photo.jpg(X)
ex) GET user/profile-photo (이때, payload의 포멧은 headers에 accept를 사용한다.)

📕 Path parameter

뒤에 리스폰스로 비어있던 DB안에 데이터가 들어가면서 무농약깐 생강이 들어가게 된다. 수정에 관련된 메소드라고 할 수 있다. PATCH PUT 둘다 수정에 관련된 API

📕 PUT vs PATCH

PUT과 PATCH는 둘다 데이터 수정을 위한 메서드이다. 그렇다면 이 두가지는 어떠한 차이점이 있을까?

PATCH, which is used to apply partial modifications to a resource

PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload

예시로, PUT요청시에 요청의 일부분만 보낸경우 나머지는 default값으로 수정되는 것이 원칙이다. 따라서 바뀌지 않는 속성도 모두 보내야한다.

또 다른 예시로, PUT HTTP 메소드로 camille라는 유저의 나이(age)를 15로 변경하고자 할 때 수정된 값만 보낼 경우 보내지 않은 데이터는 null로 변경되어 버린다.

PUT/users/1
{
	"age":15
}
HTTP/1.1 200 ok 
{
	"name" : null,
    "age" : 15 
}

따라서 PUT요청시에는 아래와 같이 변경되지 않는 데이터라도 모두 전달 해야한다.

PUT/users/1
{
  	"name" : camille,
	"age": 15
}
HTTP/1.1 200 ok 
{
	"name" : camille,
    "age" : 15 
}

그러나 PATCH를 이용해서 'age'만 변경하는 요청을 보내면, 새롭게 바뀐 부분만 반영되며 나머지는 기존의 데이터가 유지된다.

PATCH/users/1
{
	"age": 15
}
HTTP/1.1 200 ok 
{
	"name" : camille,
    "age" : 15 
}

따라서 일부 자원을 수정할 때는 PATCH를 전체적인 수정이 필요할 때는 PUT 을 이용한다.

📕 GET vs POST

💚 Get

GET method는 클라이언트에서 서버로 어떠한 리소스로 부터 정보를 요청하기 위해 사용되는 메서드이다. 데이터를 읽거나(Read), 검색(Retrieve)할 때에 사용되는 method라고 할 수 있는데,
GET은 요청을 전송할 때 URL 주소 끝에 파라미터로 포함되어 전송되며, 이 부분을 쿼리 스트링(QueryString)이라고 말한다.

ex) www.example-url.com/resources?name1=Camille&name2=Bbachon

위 예는 앞서 말한 쿼리스트링을 포함한 URL입니다. 파라미터인 name1과 name2를 통해 값을 전달받을 수 있는데, 만약, 요청 파라미터가 여러 개이면 &로 연결한다.

또, GET 요청은 오로지 데이터를 읽을 때만 사용되고 수정할 때는 전혀 사용되지 않기 땨문에 데이터 변형의 위험이 없이 사용할 수 있다.

😀 GET 요청에 대한 기타 참고 사항

GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있다.
따라서, 파라미터에 내용이 노출되기 때문에 민감한 데이터를 다룰 때 GET 요청을 사용하면 안된다.

GET 요청은 브라우저 기록에 남는다.

북마크에 추가할 수 있다.

데이터 길이에 대한 제한이 있다.

성공시, 200(Ok) HTTP 응답 코드를 XML, JSON뿐만 아니라 여러 데이터(html, txt등..), 여러 형식의 데이터와 함께 반환한다.

GET 요청은 idempotent하다.

💚 Post

POSTmethod는 리소스를 생성/업데이트하기 위해 서버에 데이터를 보내는 데 사용된다.
GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송하는데, 그 Body의 타입은 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시 따라 결정 된다.(POST로 요청을 보낼 때는 해야 한다!!)
HTTP 메세지의 Body는 길이의 제한없이 데이터를 전송할 수 있기 때문에 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있다.

앞에서 언급했던 것 처럼 POST는 데이터가 Body로 전송되고, 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬의 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야한다.

😀 Post 요청에 대한 기타 참고 사항

POST 요청은 캐시되지 않는다.

브라우저 기록에 남아 있지 않습니다.

북마크에 추가할 수 없습니다.

데이터 길이에 대한 제한이 없습니다.

자원 생성은 201(Created) HTTP 응답 코드를 반환합니다.

Post 요청은 idempotent하지 않습니다.

idempotent란?

idempotent는연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

"연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질"

동일한 연산을 여러 번 수행하더라도 동일한 결과가 나타나야 한다.

GET은 Idempotent, POST는 Non-idempotent하게 설계되었다.
여기서 GET이 Idempotent하도록 설계되었다는 것은 GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와야 한다는 것을 의미한다. 또, 이에 따라 GET은 설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않아야 Idempotent하기 때문에 주로 조회를 할 때에 사용해야한다.

예를 들어, 브라우저에서 웹페이지를 열어보거나 게시글을 읽는 등 조회를 하는 행위는 GET으로 요청하게된다고 볼 수 있다.