BerryDevelop

단순 전송 Content-Length 길이 값을 알 수 있을 때 전송하기 압축 전송 Content-Encoding:gzip Content-Length:521 압축해서 전송하는 방법, 뭘로 압축되어있는지도 같이 전송해야함. 분할 전송 Transfer-Encoding Transfer-Encoding:chunked 5 Hello 5 World 0 \r\n 이런식으로 분할해서 전송함. 용량이 큰 데이터를 보낼때 사용. Content-Length를 보내면 안됨. 범위 전송 Range, Content-Range 클라이언트 Range: bytes=1001-2000 서버 : Content-Range: bytes 1001-2000 / 2000

협상(콘덴츠 네고시에이션) 클라이언트가 선호하는 표현 요청 - Accept : 클라이언트가 선호하는 미디어 타입 전달 - Accept-Charset: 클라이언트가 선호하는 문자 인코딩 - Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 - Accept-Language: 클라이언트가 선호하는 자연 언어 협상 헤더는 요청시에만 사용 협상과 우선순위 Quality Values(q) - Quality Values(q) 값 사용 0~1, 클수록 높은 우선순위 생략하면 1 Accept-Language: ko-KR, ko;q=0.9, en-US; q=0.8. en;q=0.7 구체적인 것이 우선한다. Accept: text/*, text/plain, text/plain;format=flowed, */*..

header-filed HTTP 전송에 필요한 모든 부가정보 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보... 표준헤더가 너무 많음 필요시 임의의 헤더 추가 기능 헤더 분류 - General 헤더 : 메시지 전체에 적용되는 정보 - Reqeust 헤더 : 요청 정보 - Response 헤더 : 응답 정보 - Entity 헤더 : 엔티티 바디 정보 RFC723x 변화 - Entity -> Representation HTTP BODY - 메시지 본문(message body)을 통해 표현 데이터 전달 - 메시지 본문 = 페이로드(payload) - 표현은 요청이나 응답에서 전달할 실제 데이터 - 표현 헤더는 표현 데이터를 해석할 수 있는 정보 ..

상태코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx(Information) : 요청이 수신되어 처리중 - 거의 사용하지 않음 2xx(Successful): 요청 정상 처리 - 200 OK : 정상적으로 처리를 완료함. - 201 Created : 요청 성공해서 새로운 리소스가 생성됨 - 202 Accepted : 요청이 접수 되었으나 처리가 완료되지 않았음(배치 처리 같은 곳에서 사용 ) - 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 예) 웹 문서 편집기에서 Save 버튼 - save 버튼의 결과로 아무 내용이 없어도 된다. - save 버튼을 눌러도 같은 화면을 유지해야 한다. - 결과 내용이 없어도 204 메시..

회원 관리 시스템 API 설계 - post 기반 등록 회원 목록 /members ->GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH(부분수정), PUT(전체수정), POST 회원 삭제 /members/{id} -> DELETE POST - 신규 자원 등록 특징 - 클라이언트는 등록될 리소스의 URI를 모른다. - 회원등록 /members ->POST - POST /members - 서버가 새로 등록된 리소스 URI를 생성해준다 - 컬렉션 (Collection) 서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리 여기서 컬렉션은 /members 파일 관리 시스템 API 설계 - PUT 기..

API 설계 - post 기반 등록 회원 목록 /members GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST 회원 삭제 /members/{id} -> DELETE post 기반 등록 특징 클라이언트는 등록될 리소스의 URI를 모른다. 회원 등록 /memebers ->POST 서버가 새로 등록된 리소스 URI를 생성해준다. 컬렉션 서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리 API 설계 - put 기반 등록 파일 목록 /files -> GET 파일 조회 /files/{filename} -> GET 파일 등록 /files/{filename} -> PUT 파일 조..

전송 방법 1. 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터(검색어) 2. 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 전송 상황 1. 정적 데이터 조회 이미지, 정적 텍스트 문서 조회는 GET을 사용 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순히 조회 가능 2. 동적 데이터 조회 쿼리 파라미터 사용 쿼리 파라미터를 기반으로 정렬 필터해서 결과를 동적으로 생성 주로 검색, 게시판 목록에서 정렬 필터(검색어) 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 조회는 GET 사용 GET은 쿼리 파라미터 사용해서 데이터를 전달 3. html form 데이터 전송 -HTML Form su..

API URI 설계 리소스 식별, URI 계층 구조 활용 회원 목록조회 /read-member-list -> /members 회원 조회 /read-member-by-id -> /members/{id} 회원등록 /create-member -> /members/{id} 회원수정 /update-member -> /members/{id} 회원삭제 /delete-member -> /members/{id} uri 설계시 가장 중요한것은 리소스 식별이다. 리소스의 의미 회원을 등록하고 수정하고 조회하는게 리소스가 아니다. 회원이라는 개념 자체가 바로 리소스다. 리소스를 어떻게 식별밥법 회원이라는 리소스만 식별하면 된다-> 회원 리소스를 URI에 매핑 리소스와 행위를 분리 URI는 리소스만 식별 리소스와 해당 리소스를..

HTTP 거의 모든 형태의 데이터 전송 가능 (test, image, 음성, 영상, 파일 등등 전송 가능) 서버간에 데이터를 주고 받을 때도 대부분 http사용 JSON, XML(API) HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전 HTTP특징 클라이언트 서버 구조 무상태 프로토콜(스테이트 리스), 비연결성 HTTP메시지 단순, 확장 가능 클라이언트 서버 구조 request, response 구조 클라이언트는 서버에 요청을 보내고 응답을 대기 서버가 요청에 대한 결과를 만들어서 응답 클라이언트와 서버가 분리되어서 양쪽이 각각 발전하기 좋다. 무상태 프로토콜(stateless) stateful vs stateless차이 stateful: 서버가 클라이언트의 이전 상태를 보존하는..

URI(Uniform Resource Identifier): 자원자체를 식별하는 방법 Uniform: 리소스를 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier: 다른 항목과 구분하는데 필요한 정보 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류 될 수 있다. - URL(Resource Locator): 리소스가 있는 위치를 나타냄 - URN(Resource Name): 리소스에 이름을 부여 위치는 변할 수 있지만, 이름은 변하지 않는다. URN의 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음 URI를 URL과 같은 의미로 사용가능(실제는 URI가 더 큰 의미) URL scheme - scheme://[u..