얼렁뚱땅 개발자

이번 회사로 이직 후 서버쪽 개발 업무 중 REST API 개발이 나의 main job이 되었다. 회사에서 생산하는 기기 및 App에게 효율적으로 정보를 제공해 줄 수 있는 서버쪽 프로그래밍인 셈이다. 회사에서 생산하는 기기역시 안에 내장된 OS는 안드로이드로 되어있기 때문에 가능한 일이다. 처음 RESTFul 에 대해서 대략적이게 알고 있었지만, 실무에서는 사용하지 않았기 때문에 달랐다. 또, mean stack이나 이런 스터디로 맛뵈기 했었다고 대례 이렇겠지 짐작했었지만 역시 실무와는 달랏다. 따라서 그에 따른 내용을 한번 정리해보려고 한다. 1. REST API란 무엇인가. REST는 ROA를 따르는 웹 서비스 디자인 표준이다. ROA : Resource Oriented Architecture 출처..

HTTP status codes HTTP defines a bunch of meaningful status codes that can be returned from your API. These can be leveraged to help the API consumers route their responses accordingly. I've curated a short list of the ones that you definitely should be using: 200 OK - Response to a successful GET, PUT, PATCH or DELETE. Can also be used for a POST that doesn't result in a creation. 201 Created -..

MethodScopeSemantics GET collection Retrieve all resources in a collection GET resource Retrieve a single resource HEAD collection Retrieve all resources in a collection (header only) HEAD resource Retrieve a single resource (header only) POST collection Create a new resource in a collection PUT resource Update a resource PATCH resource Update a resource DELETE resource Delete a resource OPTIONS..

통계보기 전용뷰어 보기 출처 : http://www.iamcorean.net/22 [REST ①] RESTful 웹서비스에 대해 알아보자! RESTful 웹서비스 작성자 : 김문규 최초 작성일 : 2008. 4. 2 인터넷 업계는 OpenAPI의 열풍이 불고 있다. 너도나도 OpenAPI를 공개하... www.iamcorean.net RESTful 웹서비스 작성자 : 김문규 최초 작성일 : 2008. 4. 2 인터넷 업계는 OpenAPI의 열풍이 불고 있다. 너도나도 OpenAPI를 공개하고 있고 사용자들에게 다양한 방식의 사용을 기대하고 있다. 최근 이 OpenAPI와 함께 거론되는 기술을 당연 REST이다. 구글, 아마존, 네이버 모두가 OpenAPI를 REST 방식으로 지원한다. (물론 기존의 SO..

https://www.youtube.com/watch?v=IJ3W6xEx8Oo

네트워크를 통해 데이터베이스에 접근하는 시간 비용은 애플리케이션 서버에서 내부 메모리에 접근하는 시간 비용보다 수만에서 수십만 배 이상 비싸다. 따라서 조회환 데이터를 메모리에 캐시해서 데이터베이스 접근 횟수를 줄이면 애플이케이션 성능을 획기적으로 개선할 수 있다. 영속성 컨텍스트 내부에는 엔티티를 보관하는 저장소가 있는데 이것을 1차 캐시라한다. 일잔적인 웹 애플리케이션 환경은 트랜젝션을 시작하고 종료할 때까지만 1차 캐시가 유효하다. 하이버네이트를 포함한 대부분의 JPA 구현체들은 애플리케이션 범위의 캐시를 지원하는데 이것을 공유 캐시 또는 2차 캐시라 한다. 이런 2차 캐시를 활용하면애플리케이션 조회 성능을 향상 할 수 있다. ( JPA 책에서 현재 1차 2차 캐시 정보에 대한 부분이 나오는데, 사..

Transaction 범위 영속성 컨텍스트, 준영속 상태 스프링 컨테이너는 트랜젝션 범위의 영속성 컨텍스트 전략을 기본으로 사용한다. 한마디로 트랜잭션 범위와 영속성 컨텍스트의 생존 범위가 같다는 뜻이다. 트랜잭션을 시작할 때 영속성 컨텍스트를 생성하고 트랜잭션이 끝날 때 영속성 컨텍스트를 종료한다. 그리고 같은 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근한다. 트랜잭션이 다르면 다른 영속성 컨텍스트를 사용한다. 여러 스레드에서 동시에 요청이 와서 같은 엔티티 매니저를 사용해도 트랜잭션에 따라 접근하는 영속성 컨텍스트가 다르다. 스프링이나 J2EE 컨테이너의 가장 큰 장점은 트랜잭션과 복잡한 멀티 스레드 상황을 컨테이너가 처리해준다는 점이다. 따라서 개발자는 싱글 스레드 애플리케이션처럼 단순하게 ..

JPA가 제공하는 낙관적 락을 사용하려면 @Version 애노테이션을 사용해서 버전 관리 기능을 추가해야 한다. @Version 적용 가능 타입은 다음과 같다. Long, Integer. Short, Timestamp @Entity public class MyEntity implements Serializable { @Id @GeneratedValue private Long id; private String name; @Version private Long version; //... } Board board = em.find(Board.class, id); // transaction version = 1 // transaction 2에서 해당 게시물을 수정해서 title = "제목C", version =..

동시성 프로그래밍에서 고려되야 할 사항으로 트랜젝션 처리가 있는데, 트랜젝션 처리를 어떤 방향으로 하느냐에 따라서 성능이 좌우된다. 낙관적 락은 트랜젝션 대부분 충돌이 발생하지 않는다고 가정하는 방법이다. 쉽게 말해 애플리케이션이 제공하는 락이다. 낙관적 락은 트랜잭션을 커밋하기 전까지는 트랜잭션의 충돌을 알 수 없다는 특징이 있다. 비관적 락은 트랜잭션의 충돌이 발생한다고 가정하고 우선 락을 걸고 보는 방법이다. 데이터 베이스가 제공하는 락 기능을 사용한다. 대표적으로 select for update 구문이 있다. 추가로 데이터베이스 트랜잭션 범위를 넘어서는 문제도 있다. 예를들어 사용자 A와 B가 동시에 제목이 같은 공지사항을 수정한다고 생각해보자. 둘이 동시에 수정화면을 열어서 내용을 수정하는 중에..

준영속 상태의 가장 골치 아픈 문제는 지연로딩 기능이 동작하지 않는다는 점이다. 예를 들어 뷰 랜더링할 때 연관된 엔티티도 함께 사용해야 하는데 연관된 엔티티를 지연 로딩으로 설정해서 프록시 객체로 조회했다고 가정하자. 아직 초기화 하지 않은 프록시 객체를 사용하면 실제 데이터를 불러오려고 초기화를 시도한다. 하지만 준영속 상태는 영속성 컨텍스트가 없으므로 지연 로딩을 할 수 없다. 이때 지연 로딩을 시도하면 문제가 발생한다. 만약 하이버 네이트를 구현체로 사용하면 org.hibernate.LazyInitializationException예외가 발생한다. 준 영속 상태의 지연 로딩 문제를 해결하는 방법은 2가지가 있다. - 뷰가 필요한 엔티티를 미리 로딩해두는 방법 - OSIV를 사용해서 엔티티를 항상 ..