API

개발자라면 당연히 알아야만 할 내용 . 
 
API란 ? 메뉴판이다. 음식을 주고 받기 위한 방법이라고 볼 수 있다. 
내가 제공할 수 있는 서비스 1. 고양이 2. 호랑이 등을 제공할 수 있습다. 
 
다시 말하자면, 서버와 client가 요청을 보내고 주고 받기 위한 방법이다. 방법은 즉 코드를 의미한다.
ex) db에서 웹툰을 뽑는 코드가 있다. 이 코드를 어떻게 client가 동작시킬 것인가?
ex) app.get -> 이 url로 get을 요청한다면, 해당 웹툰뽑기 코드를 작동시킬것이다. 

Rest API->
서버에 request등으로 요청하고 응답받는것.
get put delete등이 포함되어있음.

url ->
url은 위치 /index.html등
uri는 Id등의 식별자 포함
/index는 해당 내용은 식별의 의미고 서버 안이 있진 않으니까.. uri이다

restful api는 httpmethod+urluri

 
잘못 생각한 개념이 있었다.
나는 OPEN API가 상대방이 작성한 REST API 뿐만 아니라 내부적인 METHOD까지 사용할 수 있는것으로 예측하여 그렇다면 캡슐화는 어떻게 지켜지지 싶었는데.. 그게 아니라 OPEN API의 구조는
내가 REQUEST를 보내면 - > 해당 곳에서 작업(METHOD 등) 을 하여 -> RESPONSE를 전달하는 형태였다.
 
즉 api는 어떤 주소(url)로 오면 어떤 행동을 할지. + 그 METHOD는 무엇인지. 그렇다면 어떤 일을 할지 
인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있다.  .
 
내가 짠 모든 CODE, CONTROLLER,SERVICE,REPOSITORY등등도 사실은 모두 약속이다
(어떤 METHOD로 들어오면 뭘 어디거쳐서 어떻게 하고 무슨작업을 하고...) 그러므로 모든걸 합쳐 REST API라고 할 수 있다. 
 
 
API는 틀이 있다. 1. 어떤 요청인지 (method) 2. 어떤 자료인지 (endpoint) 3. parameter. 요청에 필요한 추가 정보 (몇화, 이름) 등. REST API라는 원칙에 따라 작성하면 좋다. 
** 추가 ** 
ENDPOINT에 대한 명확한 정의가 애매 하다. 배송하려는 상대의 명확한 주소라고 이해하였으며, 사전 정의를 통해 API의 호출과 사용을 가능하게끔 한다. 
즉, ,API 클라이언트가 만든 API 호출에 대한 응답을 가져오기 위해 API호출이 상호 작용해야 하는 애플리케이션/소프트웨어의 경로/위치를 참조하는 URL이 될 것이다.
 
유저가 GET을 요청하는 코드를 짜야 , GET이 전달되고 이에 따라서 코드가 작동한다. 
우리가 아는 URL 은, 사실 API 요청을 적는 것이다. 이때 요청을 모든 사람은 할 수가 없지만, 이미지를 누르면 그러한 API가 요청이 된다. 
 
PRIVATE API와 같이, 사내에서 사용하는 API가 존재하기도 하고, PARTNER API처럼 정해진 사람만 사용할 수도 있다. 
 
 
METHOD 
 
GET -> 요소에서 데이터를 요청하는 것 (받아오는 것) .자웡늘 받아오기만 하는, SAFE METHOD라고도 불린다.
PUT -> 자원이 존재할때, 이를 변경한다. 없다면 생성되기도 한다. 단일 자원에만 수행된다
모든 정보를 다 수정하겠다. 
POST -> DATA를 내가 UPDATE 하는 것. 서버의 상태를 변등시킨다. 201 응답 코드를 받는다. 추가한다. 여러개 자원에 ㅅ행된다.
DELETE -> 자원을 삭제한다. 반복적으로 DELETE 시 , 결과가 바뀌진 않고 404or 200 (ok) 를 받는다. 
PATCH -> 부분적인 변경을 한다.  PUT과 유사하지만, 부분적인 자원의 업데이트를 의미한다 .
아무것도 없이 url에서 보내는것은? -> GET
 
 
** 추가 <멱등>
몇 번을 호출하든 최종적인 결과는 똑같은 메서드 속성입니다. 데이터를 가져오거나(GET), 삭제하거나(DELETE), 완전히 대체하는(PUT) 작업은 몇 번이 수행되건 상관없이 결과는 같습니다. 특정 데이터를 조회하는것의 결과는 조회하는 것이고, 특정 데이터를 삭제하는 것의 결과는 그 데이터가 삭제 된 것입니다.


하지만, POST의 경우는 다릅니다. POST 메서드로 결제를 수행했다고 가정해보겠습니다. 해당 POST 메소드가 두 번 호출된다면 결제가 중복해서 발생할 수 있습니다. 사용자의 돈이나 제품의 수량같은 데이터가 계속해서 달라지겠죠. 따라서, 이러한 메소드는 멱등하지 않은 것입니다.
이러한 속성은 서버의 문제로 클라이언트가 같은 요청을 다시해도 되는가? 에 대한 판단 근거가 될 수 있습니다.
 
-> 블로그에서 참조했다. 사실 post와 put 모두 기능이 유사하지만 , post는 다시 사용되면 결과가 달라질 수 있다는 
'멱등하지 않다'는 개념을 기억하자 
-> 그러므로, 3개의 field중 1개만 수정하면 put은 나머지가 null로, patch는 해당 요청만 변경된다. 
(물론, 이제 엔티티를 그대로 사용하고 이런 경우가 있지만 이렇게 짜는것을 추천받았다) 
 
즉, POST는 생성 PUT은 전체수정 PATCH는 부분수정 GET은 읽어오기 DELETE는 제거로 판단했다. 
 
 
**추가 
POST는 BODY로 통신하자 .
GET은 QUERY STRING으로 통신하자. 
 
안그래도 된다. 하지만 이렇게 약속했다. 
 
실제 사용 1) 
POSTMAN을 사용해보았다 .
 
무료로, 이전에는 다운받아야만 가능했지만 웹상으로 api를 전송해준다 .
변경 -> localhost는 지원하지않는다. 사실 당연한데 너무 믿었다.