eblo

결과 메시지 설계 Error Message 구성 field type Description httpStatus int 결과 코드, 정상인 경우 200 errorMessage String 에러 메시지 detailMessage String 에러 상세 메시지 HTTP 응답상태코드 (rfc2616 참고) 성공 200 : OK, 요청 정상 처리 201 : Created, 생성 요청 성공 202 : Accepted, 비동기 요청 성공 204 : No Content, 요청 정상 처리, 응답 데이터 없음. 실패 400 : Bad Request, 요청이 부적절 할 때, 유효성 검증 실패, 필수 값 누락 등. 401 : Unauthorized, 인증 실패, 로그인하지 않은 사용자 또는 권한 없는 사용자 처리 402 : Pa..

URI 설계 시 고려 사항 REST 서비스 프로젝트를 여러번 수행했지만 여전히 많은 시행 착오를 하고 있고 많은 도전을 받고 있습니다. 왜 이렇게해야 하는지, 왜 이런 구조인지 ... URI에 넣을 내용인지 파라미터로 전달할 것인지 등등 하지 말라고 그렇게 말해도 굳이 URI에 DELETE, UPDATE, GET등을 넣는 개발자도 많습니다. 화면과 비즈니스 로직을 분리하고 BACK-END를 개발할 때 REST 서비스는 참 좋은 가이드가 됩니다. 이 포스팅은 URI 설계에 대한 정답이라기 보다 그동안 시행 착오를 겪으면서 쌓은 경험으로 보시면 됩니다. 1. 누가 설계 할 것인가? URI만으로 어떤 서비스인지 이해할 수 있어야 하며 설계의 일관성이 유지되는 것이 중요합니다. 또 RESTFUL SERVICE가..

1. REST 소개 분산 하이퍼미디어 시스템을 위하 소프트웨어 아키텍쳐REST(Representational safe transfer)Http 프로토콜의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐 인터넷상에 REST와 관련해서 워낙 많은 정보들이 있기 때문에 자세한 내용은 생략하겠습니다. 2.REST 기본 구성REST는 기본적 구성 리소스 + 메소드 + 메시지리소스는 모든 종류의 개체, 데이터 또는 서비스이며 메소드는 행위를 의미합니다. 메시지는 요청에 대한 결과로 상태와 코드, 메시지로 구성이 되어 있습니다. 리소스REST API는 URI(Uniform Resource Idendifiter)를 중심으로 디자인되며 모든 종류의 개체, 데이터 또는 서비스가 리소스에 포함됩니다. URI 설계 규..

변화된 서비스 환경 예전에는 MVC 형태가 Web application을 만드는 표준이었습니다. 컨트롤러가 데이터를 조회해서 화면에 내려 주면 화면은 그 데이터를 이용해서 화면을 만들어 줍니다. 이러한 형태를 일반적으로 모노리틱 구조라고 합니다. 아직도 많은 서비스는 이러한 형태를 가집니다. 그런데 모바일 서비스가 활성화 되고 외부 API 서비스를 제공하면서 이런 패턴이 변화하기 시작했습니다. 서비스가 거대화 되면서 분산 서비스가 필요해지고 마이크로 서비스가 대두되었습니다. 기존 서비스가 로직과 데이터를 처리하는 서비스들로 세분화 되고 각각의 서비스가 이를 이용하는 형태를 가집니다. 대부분의 개발자들은 이런 추세를 실감하고 있을 것이고 이런 개발 요구사항을 많이 받고 있을 겁니다. 예전에도 물론 이런 요..