0221 - 0227

# 0221 - 0227

# 0222 - RESTful API POST와 PUT의 차이

# HTTP POST

# POST의 정의

Request(요청)에 포함된 Entity(Http body에 해당)을 Request-URI에 정의된 리소스의 하위(Suboridiate) Entity로 새롭게 생성하는 요청을 서버에 보낼때 사용되는 Http Method이다.

따라서 Request-URI는 리소스의 Entity를 나타내는 Collection URI여야 한다.

예를 들어, 신발들의 정보를 저장하는 shoes가 있다. 그리고 각 신발의 정보들은 shoes라는 큰 카테고리 밑에 하위 item으로 등록되고 저장될 것이다. 그렇다면, shoes는 신발들이 모인 Collection이다. 이걸 URI로 적용해본다면 신발 정보의 Collection-URI는 /shoes가 된다.

POST는 /shoes 라는 collection URI의 하위에 새로운 신발(Entity)을 Create(생성)할 때 사용되는 http Method라고 할 수 있다.

# POST의 특징

POST Request는 Idempotent(멱등) 하지 않다 :
Idempotent(멱등) 하지 않다 = 여러번의 재시도에 대한 모든 결과값이 동일하지 않다는 것이다. 즉, POST로 동일한 entity의 Request를 N번 보낸다면, N개의 다른 리소스들이 생성되는 것이다.
POST Request의 Response는 Caching 가능 하다 :
POST request는 Cache-Control or Expires가 Http header 올바르게 정의되어 있다면 Response(응답) 값을 캐싱해도 된다. 대신 Response를 캐시로 응답 했다면, HTTP 300으로 해당 응답이 캐시에서 왔따는 것을 표시해줘야 한다.

# HTTP PUT

# PUT의 정의

Request-URI에 있는 Resource가 존재한다면, Request에 있는 Entity에 값으로 리소스를 Update(갱신)한다.

만약 Resource가 존재하지 않고, Request-URI와 Resource-URI가 올바르다면 리소스를 Create(생성) 할 때 사용되는 Http Method이다.

if resource 존재 -> Update(갱신) else -> Create(생성)

# PUT의 특징

Resource Identifier :
PUT은 기존의 /shoes 라는 collection URI에 더하여, /shoes/{shoe_id}로 해당 resource의 Resource Identifier를 나타내줘야 한다.
PUT Request는 Idempotent(멱등) 하다 :
PUT request로는 새로운 정보가 계속되서 생성되지 않는다. 여러번 재시도를 하더라도, 동일한 결과 값을 받는다. 즉 PUT request는 idempotent(멱등)하다.
POST Request의 Response는 Caching 할 수 없다 :
PUT request는 idempotent하다. 하지만 Response(응답) 값을 캐싱하면 안된다.

# PATCH와의 차이

PATCH는 수정만 담당하며 리소스의 일부분만 수정할 때 사용하고, PUT은 리소스의 모든 속성을 수정하기 위해 사용한다.

# POST & PUT 예시

POST /shoes
= Http Body에 있는 정보로 새로운 Shoe 하위 Resource 생성

PUT /shoes/{존재하는_SHOE_ID}
= 존재하는_SHOE_ID에 존재하던 정보를 Overwrite(덮어쓰기)해서 정보를 갱신

PUT /shoes/{존재하지_않는_SHOE_ID}
= 존재하지_않는_SHOE_ID로 새로운 Resource 생성

# 0227 - Interface vs Abstract

Interface와 Abstract Class는 상속(extends)받거나, 구현(implements)하는 Class가 Interface나 Abstract Class 안에 있는 Abstract Method를 구현하도록 강제하는 공통점을 가지고 있다. 그렇다면 차이점은 존재 목적이 다른 부분이다.

# Interface

interface는 부모, 자식 관계인 상속 관계에 얽메이지 않고, 공통 기능이 필요 할때, Abstract Method를 정의해놓고 구현하는 Class에서 각 기능들을 Overriding하여 여러가지 형태로 구현할 수 있기에 다형성과 연관되어 있다.

interface는 해당 인터페이스를 구현하는 Class들에 대해 동일한 method, 동작을 강제하기위해 존재한다.

Java에서 다중 상속이 안되어 발생하는 Abstract Class의 한계도 보완해줄 수 있다. Interface의 implements에는 제한이 없어 다중 구현이 가능하다. 하지만 모든 Class가 Interface를 이용한다면, 공통적으로 필요한 기능도 implements하는 모든 Class에서 Overriding해 재정의해야 하는 번거로움이 존재한다.

interface는 각각 다른 Abstract Class를 상속하는 Class들의 공통 기능을 명시할때 사용하면 편리하다

# Abstract Class

Abstract Class는 부모와 자식 즉, 상속 관계에서 Abstract Class를 상속(extends)받으며 같으 부모를 상속받는 자식 Class들 간에 공통 기능을 각각 구현하고, 확장시키며 상속과 관련되어 있다. 상속은 Super Class의 기능을 이용, 확장 하기 위해 사용된다.

Abstract Class는 IS - A "~이다"이고, Interface는 HAS - A "~를 할 수 있는"이다.

Abstract Class를 상속하여 Class들간의 구분이 가능해진다. Java에서는 다중 상속을 지원하지 않기 때문에 Abstract Class 만으로 구현하는 Abstract Method를 강제하는데는 한계가 존재한다.

0211 - 0220 0228 - 0313