이전에 RESTful api에 대한 내용을 정리한 적이 있는데 너무 부족하다고 생각해서 조금 더 작성합니다. 용어에 대한 이해가 안되니까 제가 제 코드에 대해 자신이 없어서 이해를 하기 위한 시도 중 하나입니다! (출처: 코드스테이츠)
RESTful api(REpresentational State Transfer api)
웹서비스를 만드는데 사용되는 제약모음. 서버에게 요청을 보낼때 해당 api를 따라서 요청해야한다. 많은 종류의 api가 웹상에 존재하고 각각의 api마다 제약들이 다 달라서 클라이언트가 요청을 할 때마다 새로운 형식의 요청을 보내야했습니다. 이를 비슷한 스타일로 만들어서 다른 api를 요청할 때도 편하게 만들 수 있도록 한 것이 RESTful api입니다.
RESTful api 제약들
1. client-server
클라이언트-서버관계를 유지해야 합니다. 각각 독립적으로 발전할 수 있어야하고 클라이언트에 다른 서버를 연결해도 클라이언트가 돌아갈 수 있도록 만들어야한다.
2. stateless
무상태성. 요청했던 정보를 기억하지 않습니다.
3. cacheable
서버에 송신할 때 마다 정보를 가져오기엔 정보가 많아 지면 오래걸리니까 특정 정보를 서버에 저장할 수 있게 해야한다.
4. uniform interface
같은 스타일의 api 형식으로 만들어져야한다.
여기서 uniform interface의 형식에 대한 조건이 있습니다(으아..ㅠ)
uniform interface의 조건
4-1. 리소스는 식별 가능해야한다.
4-2. 리소스를 표현에 의해서 조작할 수 있어야한다.(표현하는 것 = 요청하는 것)
4-3. 정보를 조작하기 위해 보내는 메시지에는 필요한 모든 정보가 다 있어야한다.
4-4. 링크가 있어야한다. (HATEOAS)hypermedia as the engine of application state
*리소스 : rest에서 정보의 가장 핵심적인 추상화는 리소스다. 이름 붙일 수 있는 정보면 어떤 것이든 리소스가 될 수 있다.
5. layered system
서버가 어떤방식으로 구성되어있고 어떻게 돌아가는지 알 필요가 없어도 클라이언트가 api를 사용할 수 있게 만들어야한다.
6. code on demand
수행할 수 있는 코드를 내려줄 수 있어야한다.(자바스크립트 같은 코드를 말합니다.)
RESTful api를 만족하게 uri를 작성하기 위해서는 다음과 같은 과정이 필요합니다!
Best Practices
- 리소스를 나타내는데 명사를 사용한다. 변수명을 명사로 사용하길 권장합니다.
- 일관성있게 작성한다.
2-1. 계층구조를 나타낼 때는 / 사용
2-2. uri 끝에 /를 붙이지마라
2-3. uri 가독성을 높이기 위해 - 사용금지
2-4. _사용금지
2-5. uri에 소문자 사용금지
2-6. 파일확장자를 사용하지마라 - CRUD 기능 이름은 uri에 사용 금지(create, read, update, delete). 관용어구는 의미가 헷갈릴 수 있으니 사용을 하지 않는 것이 좋겠습니다.
- filter가 필요하면 query component를 사용하자. uri를 보면 /를 사용하여 계층으로 하나하나 내려가기 보다 ?를 사용하여 필터를 사용해주는 것을 말합니다.
흐...일단 최대한 정리한 대로 적기는 했지만 막상 restful api를 설명해보라고 한다면 'api를 요청하기 위해 정해진 제약들' 이라고 밖에 설명을 하지 못하겠습니다ㅠㅜ 틈틈히 봐주면서 눈에 익히는 연습을 해야겠습니다.
