![URI 예약문자, 인코딩
예약문자
! * ' ( ) ; : @ & = + $ , / ? # [ ]
!!! Urlencode !!!
https://ko.wikipedia.org/wiki/
%ED%8D%BC%EC%84%BC%ED%8A%B8_%EC%9D%B8%EC
%BD%94%EB%94%A9
“…/wiki/” + 변수 (우리 이러지 말자)
문자열 규칙 - RFC 3986
https://tools.ietf.org/html/rfc3986
https://ko.wikipedia.org/wiki/퍼센트_인코딩](https://image.slidesharecdn.com/restful-180318163825/85/Restful-Getting-to-know-the-RESTful-27-320.jpg)
Restful 제대로 알기(Getting to know the RESTful)
- 3. REST
- 5. Architectural Styles and the Design of Network-based Software Architectures, 2000, 논문 Roy T. Fielding 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처
- 6. 생각과는 다르게 REST는 표준규약, 스펙 이 아니다.
- 7. 안타깝게도 REST는 디자인패턴, 아키텍처 이므로 반드시 따라야 할 규칙이 없다.
- 9. 뭐가 다를까?
- 10. SOAP
- 11. WSDL 작성 → UDDI 등록 → SOAP 요청
- 13. REST API 착각
- 14. 단순히 화면 대신에 json 내려주는 서비스??
- 15. GET 으로만 구성해도 서비스만 되면 그만?? GET /car?method=getCar GET /car?method=saveCar GET /car?method=updateCar GET /car?method=deleteCar RESTful API는 RPC가 아니다
- 16. URL이 긴 것은 싫으니까 약어로?? GET /cr?rgsid=1234 API는 Client와의 대화 불친절한 약어 지양
- 19. REST는 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처
- 20. 그게 뭐냐면... 웹브라우저 URL 에서 쓰이는 그놈 웹서버와 통신하는 통신규약
- 23. 요청은 이렇게 POST /credit/123 HTTP/1.1 Accept : application/json Host : api.encar.com … {“paymentId” : 324, “userId”:”seller”} 시작줄:헤더:본문
- 24. URI || URL + URN Resource를 식별 URI
- 25. Schema :// Host : Port / Path https://api.encar.com/credit Default Port 80, 443 URI - URL
- 26. /Path ? Key = value#fragement /credit?carId=123#main 겁나쉽군^^ URI - URN
- 27. URI 예약문자, 인코딩 예약문자 ! * ' ( ) ; : @ & = + $ , / ? # [ ] !!! Urlencode !!! https://ko.wikipedia.org/wiki/ %ED%8D%BC%EC%84%BC%ED%8A%B8_%EC%9D%B8%EC %BD%94%EB%94%A9 “…/wiki/” + 변수 (우리 이러지 말자) 문자열 규칙 - RFC 3986 https://tools.ietf.org/html/rfc3986 https://ko.wikipedia.org/wiki/퍼센트_인코딩
- 28. OPTIONS : 가능한 method를 확인한다 GET : 요청 URI 의 자원을 가져온다 POST : 요청 URI 의 신규 자원을 보낸다 PUT : 요청 URI 의 자원의 정보를 저장한다 DELETE : 요청 URI 의 자원을 삭제한다 HEAD : GET 요청에 HEAD만 받는다 TRACE : 보낸 메시지를 다시 돌려준다 CONNECT : proxy 에서 사용 Method Body
- 32. 응답은 이렇게 HTTP/1.1 200 OK Content-Type : application/json Content-Length : 11 … {“paymentId” : 324, “userId”:”seller”} 시작줄:헤더:본문
- 33. 응답코드 200 성공 201 성공, 자원을 생성 202 허용함 204 컨텐츠가 없음 301 지정 URL로 리다이렉트 400 요청자가 무언가 잘못함 401 권한이 없음 (인증관련) 403 금지됨 (사용제한) 404 존재하지 않음 500 서비스에러 (개발자 잘못) 503 서버다운 (인프라 잘못) https://ko.wikipedia.org/wiki/HTTP_상태_코드
- 34. body GET : 존재 O – 조회 목적 POST : 존재 X – 등록 목적 PUT : 존재 X – 저장 목적 DELETE : 존재 X – 삭제 목적 POST 에서 요청에 대한 응답을 요구하지 말자 응답코드는 괜히 있는 것이 아니다 정상 응답했다면 믿어라
- 35. RESTful API
- 36. URI 자원은 명사 DELETE /credits GET /credits/cancel POST /credits?action=cancel Credit(신용) 에 대한 API 유추 동작은 Method로 정의!!! 제발!!
- 37. URI 자원 ID는 URI로 명시적 표기 GET /credits/12345 GET /credits?id=12345 기능적 문제 X 단, URI와 Method로 API 표현 강화
- 38. URI 자원은 여러개 GET /credit/12345 GET /credits/12345 단일 자원이 아닌 경우 복수의 이름으로 그 속성을 정의한다.
- 39. Status Code Body는 데이터를 위한 공간 POST /credits → 응답 400(잘못된 요청) POST /credits → 응답 200(정상?) {“success” : false} 모든 요청은 응답코드로 판단 과연 200과 false는 정상인가 실패인가?
- 40. Status Code 의미전달 GET /credits → 응답 204 GET /credits → 응답 200 -- empty body -- Client 에게 충분한 정보를 제공필요 만약 데이터가 없는 것이 에러라면 400, 500
- 42. 왜 REST인가?
- 44. HTTP가 가지는 장점을 그대로 Stateless Cacheable Self-descriptiveness
- 45. Domain : Resource 도메인 주도개발
- 46. REST 약점
- 47. Defector 표준
- 49. 빚이 많으면 파산하듯 기술 부채가 많아지면 서비스가 파산한다
- 50. API 333 전략 “3초만에 API를 이해하고, 30초만에 API 키를 발급 받아서, 3분안에 첫번째 요청이 오도록 해라” http://channy.creation.net/blog/904