[HTTP의 상태코드와 메서드(GET,POST,PATCH,DELETE)]
1XX (정보): 요청을 받았으며 프로세스를 계속한다
2XX (성공): 요청을 성공적으로 받았으며 인식했고 수용합니다
-200 OK: 요청이 성공적으로 되었습니다
-201 Created: 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다.
3XX (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
-301 Moved Permanently: 이 응답코드는 요청한 리소스의 URI가 변경되었음을 의미합니다.
변경된 새로운 URI를 응답에서 주는 것이 좋습니다.
4XX (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다.
-400 Bad Request: 이 응답은 잘못된 문법으로 인하여 서버가 요청을 이해할수 없음을 의미합니다.
-404 Unathourized 클라이언트의 인증이 되지 않음을 의미합니다.
5XX (서버오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다
-500 Internal Server Error: 서버에 오류가 있음을 의미합니다.
POST: 자원을 생성
보통 하위자원을 생성하는데. 예를 들어 book 테이블안의 데이터를 생성하는..
성공적으로 생성되면 HTTP 상태 201을 반환
GET: 읽기
성공시 200, 오류의 경우 가장 자주 404(NOT FOUND) 또는 400 (BAD REQUEST)을 반환합니다.
데이터를 수정, 삭제하는데 반드시 사용하면 안됨
PUT: 업데이트(전체 자원)
-요청을 보낼 때 전체를 보내야 함.
PATCH: 업데이트(일부 자원)
-요청을 보낼 때 수정하는 일부분을 보내야 함.
DELETE: 삭제
[REST API]
API란? Application Programming interface
API는 소프트웨어와 소프트웨어 사이 데이터 전송을 가능하게 하는 프로그램
REST API
웹의 장점을 잘 살린 아케텍처이며 먼저 이 아키텍쳐는 Uniform-Interface를 갖는것이 특징
Uniform-Interface
자원들이 각각의 독립적인 인터페이스를 가져야합니다
-웹페이지를 변경했다고 웹 브라우저를 업데이트하는 일은 없어야 합니다
-HTTP 명세나 HTML 명세가 변경되어도 웹페이지는 잘 작동해야 합니다.
그리고 이 아키텍처의 규칙은 다음과 같습니다
1. Self-descriptive messages
HTTP Header에 타입을 명시하고 각 메시지(자원)들은 MIME types에 맞춰 표현되어야 합니다
예를 들어 .json를 반환한다면 application/json으로 명시해주어야합니다. MIME types는 문서, 파일 등의 특성과 형식을 나타내는 표준입니다. IETF의 RFC6838에 정의 및 표준화되어 있습니다.
2.HATEOAS 구조
하이퍼링크에 따라 다른 페이지를 보여줘야 하며 데이터마다 어떤 URL에서 원했는지 명시해주어야 합니다
3.Stateless
이 규칙은 HTTP 자체가 Stateless이기 때문에 HTTP를 이용하는 것만으로도 만족됩니다.
즉 REST API를 제공해주는 서버는 세션(session)을 해당 서버 쪽에 유지하지 앟는다는 의미
4.Cacheable
HTTP는 원래 캐싱이 됩니다. 새로고침을 하면 304가 뜨면서 원래 있던 js와 css이미지 등을 불러 오는 것을 볼 수 있습니다. 이러한 캐싱은 네트워크 요청을 줄여주며 이는 UX 향상에 도움이 됩니다. 네트워크 요청 시 해당되는 자원들을 복사해서 메모리에 저장해두었다가 또 같은 요청 시 네트워크 요청을 하지 않고 브라우저메모리에 있던 자원을 다시 반환합니다. HTTP 메서드 중 GET에 한정되며 'Cache-Control:max-age=100'(100초) 이런 식으로 한정된 시간을 정할 수가 있으며 캐싱된 데이터가 유효한지를 판단하기 위해 'Last-modifed'와 'Etag'를 씁니다.
'Etag'는 전달되는 값에 태그를 붙여서 캐싱되는 자원인지를 확인해주는 것입니다.
이거 맞아?? 하면서... Etag나 last modifed를 기준으로 캐싱된 데이터의 붙여지는태그
- Client-Server 구조
클라이언트와 서버가 서로 독립적인 구조를 가져야 합니다. 물론 이는 HTTP를 통해 가능한 구조입니다. 서버에서 HTTP 표준만 지킨다면 웹에서는 그에 따른 화면이 잘 나타나게 됩니다. 서버는 그저 API를 제공하고 그 API에 맞는 비즈니스 로직을 처리하면 됩니다. 마찬가지로 클라이언트에서 HTTP로 받는 로직만 잘 처리하면 되는 것입니다.
6.Layered System
계층구조로 아키텍처를 만들 수 있다는 것을 뜻합니다.
URI 규칙
URI 규칙 이렇게 규칙을 지켰으면 이제 자원을 표기하는 URI에 아래의 6가지 규칙을 적용해야함
1. 동작은 HTTP 메소드로 해야합니다. 수정=PUT , 삭제=DELETE, 추가=POST 조회=GET
을 이용해야 합니다
2. 확장자는 표기하지 말아야 합니다
3. 동사가 아닌 명사로만 표기해야합니다
4. URI는 계층적인 내용을 담고 있습니다.
5. 소문자로 쓰며 너무 길 경우에는 -를 씁니다.
6. HTTP 응답 상태코드를 활용합니다.
