Routing & Controller
애플리케이션이 사용자의 요청을 어떻게 해석하여 응답을 반환하는지(라우팅)와 라우트를 어떻게 정의하는지를 이해하고 server와 client의 유기적인 데이트 flow를 이해한다.
3-1 MVC, HTTP, RESTful route, HTTP status code
- MVC 디자인 패턴에 대해서는
https://velog.io/@chaos663/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-MVC-MVP-MVVM-%ED%8C%A8%ED%84%B4
이 링크를 들어가면 정리를 해놓았다.
- HTTP Method
가장 일반적인 method는 GET, POST 이고 그 다음으로는 PUT, DELETE이다. 다른 것들도 많은데 이 method들을 가장 많이 사용한다.
이미지 출처 : https://loy124.tistory.com/368
- GET : 리소스를 조회 할때 사용한다.
서버에 데이터를 전송 할 때는 query를 사용해서 전달한다.(?data=user&value=user_id)
body에 데이터를 전달 할 수 있으나 지원하지 않는 곳이 많아 권장 되지 않는다.
- GET방식의 경우, URL에 REQUEST하는 data가 포함되어있어서 개인정보같은 경우는 POST방식으로 REQUEST하는 것이 좋다!
- POST : 요청 데이터 처리, 주로 등록에 사용한다. body를 통해 서버로 요청 데이터를 전달한다. 주로 신규 리소스 등록(ex.회원,게시글), 프로세스 처리(ex.결제->배송)에 사용된다.
- PUT : 리소스가 있으면 해당 리소스를 완전히 대체하고 , 해당 리소스가 없으면 생성한다.
클라이언트가 리소스에 대한 위치를 알고 있다 ex): api/users/1- DELETE : 리소스를 삭제한다.
- HEAD : GET과 동일하지만 메시지 부분을 제외하고 status line과 header만 Return한다. 웹 서버 정보 확인, 버전, 상태 체크의 용도로 사용된다.
- PATCH : 리소스 부분 변경할 때 사용한다
PUT방식은 전체를 대체하는 방식이기 때문에 PATCH로 부분 변경을 진행한다.
(PATCH 지원이 안되는 경우 POST를 사용한다)- OPTIONS : 해당 서버에서 지원가능한 HTTP Method들을 확인 하기 위해 사용한다.
(주로 CORS에 사용한다)- CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정하는데, 주로 Proxy를 사용할 때 사용한다.
- TRACE : 요청 리소스에 대해서 모든 경로를 보여 준다.(보안상의 이유로 주로 사용되지 않게 막는다)대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
- 루프백 : 루프백(Loopback, loop-back)이란 전기신호의 라우팅, 디지털 데이터 스트림(digital data streams), 또는 품목의 흐름이 의도적인 가공이나 수정 없이 원래의 장치나 장비로 돌아가는 것을 말한다. 이것은 주로 전송이나 수송 기반 시설을 테스트하는 수단으로 사용된다.
- 가상 루프백 인터페이스 (TCP/IP)
인터넷 프로토콜 스위트(Internet Protocol Suite)의 구현은 가상 네트워크 인터페이스를 포함한다. 같은 기기에서 작동하는 네트워크 응용 프로그램 클라이언트와 서버는 이 인터페이스를 통해 통신할 수 있다. 이 인터페이스는 운영 체제의 네트워킹 소프트웨어 내에서 완전히 구현되며 네트워크 인터페이스 컨트롤러에 패킷을 보내지 않는다. 컴퓨터 프로그램이 루프백 IP 주소로 보낼 수 있는 어떠한 트래픽도 다른 장치로부터 수신한 것처럼 간단하고 빠르게 네트워크 소프트웨어 스택으로 다시 보내진다.
| HTTP Method | URL | Controller Method | Route Name | Description |
|---|---|---|---|---|
| GET | tasks | index( ) | tasks.index | 모든 task 조회 |
| GET | tasks/create | create( ) | tasks.create | 새 task 생성을 위한 입력 폼 화면 출력 |
| POST | tasks | store( ) | tasks.store | 입력된 내용으로 새 task 생성 |
| GET | tasks/{task} | show( ) | tasks.show | task 하나 조회 |
| GET | tasks/{task} | edit( ) | tasks.edit | task의 수정 폼 화면 출력 |
| PUT/PATCH | tasks/{task} | update( ) | tasks.update | 입력된 내용으로 task 수정 |
| DELETE | tasks/{task} | delete( ) | tasks.destroy | task 하나 삭제 |
교재의 라라벨의 리소스 컨트롤러에 해당하는 HTTP METHOD LIST
-Restful?
REST(Representational state transfer)는 API를 작성하기 위한 설계 스타일이다.
여기서 REST를 정리해보자!!
RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스
REST의 구조에는 다음이 있다.
- 자원(RESOURCE) - URI
- 행위(Verb) - HTTP METHOD
- 표현(Representations)
- REST 의 특징
특징 중 라라벨에서 말하는 RESTful의 특징은
- 한 번에 하나의 리소스(예를 들어 task)를 중심으로 구조화된다.
- HTTP 메서드를 사용하여 예상하기 쉬운 URL 구조로 API가 작동하도록 구성
- 주로 JSON 형식의 데이터를 반환하고 경우에 따라 JSON 형식으로 HTTP 요청을 받는다.
일반적인 RESTful의 특징은 아래와 같다!
1) Uniform (유니폼 인터페이스)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.
2) Stateless (무상태성)
REST는 무상태성 성격을 갖는다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 그래서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
3) Cacheable (캐시 가능)
REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능.
여기서, 또! Cashing이란 무슨 말인가??
- cashing
cash : 캐시는 컴퓨터의 성능을 향상시기기 위해 사용되는 메모리인데 주기억장치와 CPU사이에 위치하고, 자주 사용하는 데이터들을 기억한다.
cashing :
캐싱은 이 캐시 영역으로 데이터를 가져와서 접근하는 방식
예를 들면, 속도가 느린 디스크의 데이터를 속도가 빠른 메모리로 가져와서 메모리상에서 읽고 쓰는 작업을 수행(데이터를 디스크에서 처리하는 것이 아니라 메모리에서 처리한다는 말(디스크보다 메모리에서 처리하는 것이 빠르다는 것은 알쥬?!))
4) Self-descriptiveness (자체 표현 구조)
REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것.
5) Client - Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.
개발에 있어서 client와 server를 구분하여 개발할 수 있다는 점(의존성이 떨어진다로 표현하면 된다.)은 개발의 속도에 있어서 빠른 개발을 할 수 있게 한다는 장점이 있다.
6) 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
REST API 중심 규칙
- 첫 번째, URI는 정보의 자원을 표현해야 한다.(리소스명은 동사보다는 명사를 사용)
GET /members/delete/1
- 위와 같은 방식은 REST를 제대로 적용하지 않은 URI.
URI는 자원을 표현하는데 중점을 두어야 하기에 delete와 같은 행위에 대한 표현이 들어가서는 안됨!- 두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
- 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현
DELETE /members/1
- 회원정보를 가져올 때는 GET, 회원 추가 시의 행위를 표현하고자 할 때는 POST METHOD를 사용하여 표현
ex) 회원정보를 가져오는 URI
GET /members/1
ex) 회원을 추가할 때POST /members/2
URI 설계 시 주의할 점
- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
http://restapi.example.com/dinosours/rex http://restapi.example.com/animals/mammals/humans- URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다. REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
http://restapi.example.com/dinosours/rex- 하이픈(-)은 URI 가독성을 높이는데 사용
URI를 쉽게 읽고 해석하기 위해, 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.- 밑줄(_)은 URI에 사용하지 않는다.
글꼴에 따라 다르긴 하지만 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 합니다. 이런 문제를 피하기 위해 밑줄 대신 하이픈(-)을 사용하는 것이 좋다.- URI 경로에는 소문자가 적합하다.
- 파일 확장자는 URI에 포함시키지 않는다.
HTTP RESPONSE STATUS CODE
(모든 STATUS는 너무 많으므로 많이 사용하는 것 위주로!)
| STATUS CODE | DESCRIPTION |
|---|---|
| 1XX(정보) | 요청을 받았으며 프로세스를 계속 진행함 |
| 100 | 진행 중임을 의미(Continue) |
| 101 | 클라이언트에 의해 보낸 업그레이드 요청 헤더에 대한 응답(Switching Protocol) |
| 102 | 서버가 요청을 수신 그리고 처리하고 있지만, 제대로 된 응답을 알려 줄 수 없음을 의미(Processing) |
| 2XX(성공) | 요청을 성공적으로 받았으며 인식했고 수용함 |
| 200 | 클라이언트의 요청을 정상적으로 수행함(OK) |
| 201 | 클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시)(Created) |
| 202 | 요청을 수신하였지만 그에 응하여 행동할 수 없음(Accepted) |
| 203 | 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지않지만, 로컬이나 서드 파티 복사본에서 모아졌음을 의미 |
| 3XX(리다이렉션) | 요청 완료를 위해 추가 작업 조치가 필요함 |
| 301 | 요청한 리소스의 URI가 변경되었음을 의미 |
| 302 | 요청한 리소스의 URI가 일시적으로 변경되었음을 의미 |
| 303 | 클라이언트가 요청한 리소스를 다른 URI에서 GET요청을 얻어야 할 때, 서버가 클라이언트로 직접 보내는 응답 |
| 304 | 캐시를 목적으로 사용되는 코드. 클라이언트에게 응답이 수정되지않았음을 알림 |
| 305 | 요청한 응답은 반드시 Proxy를 통해서 접속해야 하는 것을 알려줌 |
| 307 | 클라이언트가 요청한 리소스가 다른 URI에 있으며, 이전 요청과 동일한 메소드를 사용하여 요청할 때, 서버가 클라이언트에게 보냄 |
| 308 | 리소스가 이제 HTTP 응답 헤더의 Location에 명시된 영구히 다른 URI에 위치하고 있음을 의미 |
| 4XX(클라이언트 오류) | 요청의 문법이 잘못되었거나 요청을 처리할 수 없음 |
| 400 | 잘못된 분법으로 인하여 서버가 요청하여 이해할 수 없음(Bad Request) |
| 401 | HTTP 표준에서는 미승인(unauthorized), 의미상 이 응답은 비인증(unauthenticated)을 의미. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로 인증해야 함(Unauthorized) |
| 403 | 클라이언트는 콘텐츠에 접근할 권리가 없음을 의미.401과 다른 점은 403은 서버가 클라이언트가 누구인지 알고 있음(Forbidden) |
| 405 | 클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드 |
| 404 | 서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미. 그리고 API에서는 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수 있음. 서버는 인증받지 않은 클라이언트들로부터 리소스를 숨기기위해 이 응답을 403으로 처리 할 수 있음 |
| 408 | 요청을 한 지 시간이 오래된 연결에 일부 서버가 전송. 서버가 사용되지 않는 연결을 끊고 싶어하는 것을 의미(Request Timeout) |
| 5XX(서버 오류) | 서버가 명백히 유효한 요청에 대한 충족을 실패함 |
| 500 | 웹 사이트 서버에 문제가 있음을 의미(Internal Server Error) |
| 501 | 서버가 요청을 이행하는 데 필요한 기능을 지원하지 않음을 의미(Not Implemented) |
| 502 | 서버가 게이트웨이로부터 잘못된 응답을 수신했음을 의미(Bad Gateway) |
| 503 | 서버가 요청을 처리할 준비가 되지 않았습니다를 의미 |
| 504 | 웹페이지를 로드하거나 브라우저에서 다른 요청을 채우려는동안 한 서버가 Access하고 있는 다른 서버에서 적시에 응답을 받지 못함을 의미(Gateway Timeout) |
| 505 | 서버에서 지원되지 않는 HTTP 버전을 클라이언트가 요청하였을 때의 status code! |
| 506 | 서버 내부 구성에 오류가 있는 경우 발생 |
| 508 | 서버가 요청을 처리하는 동안 무한 루프를 감지한 경우 발생 |
| 511 | 클라이언트가 네트워크 액세스를 하기 위해서는 인증할 필요가 있음을 나타냄(Network Authentication Required) |
3-2 Definition of Route
라라벨 애플리케이션에서 브라우저를 통한 웹 접근용 라우트는 routes/web.php 파일에, API용 라우트는 routes/api.php 파일에 정의한다.
웹 접근용은 일반 사용자가 방문하는 URL이고, API 라우트는 API를 위한 URL 이다.
라라벨에서 특정 URL과 매칭되는 라우트를 정의하는 가장 간단한 방법은 클로저를 사용하는 방법
// routes/web.php
Route::get('/', function(){
return 'Hello, World !';
})클라이언트가 도메인의 '/'로 접근하면, 라라벨의 라우터는 정의된 클로저를 실행하고 결과를 반환한다.
위의 코드에서 왜 echo를 안쓰고 문자열을 반환하였는지??
라라벨 애플리케이션이 처리하는 요청/응답 생명주기에는 라우트 처리 로직을 앞뒤로 둘러싼 추가 작업이 많기 때문!!
반환된 문자열을 기반으로 응답 객체를 만들고 이 객체에 추가적인 로직을 실행한 후에야 최종적으로 사용자에게 응답을 보냄. 이 로직 중 일부는 Middleware라고 부르는데, 나중에 자세히 살펴볼 것이다.
요청/응답 생명주기란??
요청에서 응답까지 한 싸이클을 한 주기로 해서 그 사이에 일어나는 일들을 요청/응답 생명주기라고 한다.
요청은 전역 > 컨트롤러 > 라우터의 순서대로 동작하지만, 응답은 라우터 > 컨트롤러 > 전역으로 동작
라라벨의 생명주기
- 시작점은 public/index.php파일로부터 시작이된다.
웹서버(Apache/Nginx)의 설정에 따라 모든 요청은 이 파일에 전달된다.
index.php 파일은 컴포저가 생성 한 오토로더 정의를 로딩한다.
그리고 bootstrap/app.php에서 라라벨 애플리케이션의 인스턴스를 가져와 서비스 컨테이너 인스턴스를 생성한다.- 다음으로는, 유형에 따라 전송된 요청을 HTTP kernel이나 console kernel 둘 중 하나로 보낸다. 모든 request의 흐름의 중심에서 이 두 가지 kernel이 작동하게 된다.
app/Http/Kernel.php에서 볼 수 있다.
HTTP 커널은 요청이 실행되기 전에 실행될 bootstrappers 배열을 정의하는 Illuminate\Foundation\Kernel 클래스를 확장한다. bootstrappers는 오류 처리를 구성하고, 로깅을 구성하고, 애플리케이션 환경을 감지하고, 요청이 실제로 처리되기 전에 수행해야 하는 기타 작업을 수행한다. 일반적으로, 신경 쓸 필요가 없는 라라벨 내부 설정을 처리한다.
HTTP Kernel은 또한 모든 요청이 애플리케이션에서 처리되기 전에 통과해야하는 HTTP Middleware 목록을 관리한다.(Middleware는 HTTP session 읽기 및 쓰기, 애플리케이션 확인, CSRF 토큰 확인 등을 처리)
HTTP kernel의 handle 메서드(handle( ))는 Request를 수신, Response를 반환한다. 즉, HTTP Request를 처리하여 HTTP Response를 하는 것이 바로 kernel의 handle( ) method 이다.
Service Providers
kernel Bootstrap의 작업 중 하나는 애플리케이션의 서비스 프로바이더를 로드하는 것이다. 그에 대한 설정은config/app.php설정 파일의 providers 배열에서 관리한다.
라라벨은 이 서비스 프로바이더 목록을 각각 인스턴스화 한다. 그리고 모든 프로바이더에서 register( ) method가 호출된다.
모든 프로바이더가 등록이 되면 각 프로바이더에서 boot ( ) 메서드가 호출된다. 일반적으로 라라벨에서 제공하는 모든 주요 기능들은 이 서비스 프로바이더에서 구성하기때문에 이것을 로드하는 프로세스는 상당히 중요하다고 한다.
Routing
애플리케이션에서 가장 중요한 서비스 프로바이더 중 하나는,App\Providers\RouteServiceProvider이다. 이 서비스 프로바이더는 애플리케이션의 routes 디렉토리에 포함된 경로-route 파일을 로드한다.
- 다음으로, 애플리케이션이 bootstrap되고 모든 service provider가 등록이되면, Request가 실행을 위해 Router로 전달된다.
- Router는 Request를 route나 Controller로 dispatch 하고, 라우트별 미들웨어를 실행한다.
- Request가 일치하는 경로에 할당된 모든 Middleware를 통과하면, Route or Controller method가 실행이 되고, Route or Controller method에서 반환된 Response는 경로의 Middleware Chain을 통해 다시 전송된다.
- Response가 반환이되면, Response는 route의 middleware를 통해 외부로 다시 이동하여 애플리케이션이 나가는 응답을 수정하거나 검사할 수 있다.
- Response가 Middleware를 통해 다시 이동을하면 , HTTP kernel의 handle( ) method가 Response 인스턴스를 반환하고, index.php 파일이 반환된 Response에 대해 send 메서드를 호출한다.
- send 메서드는 응답 내용을 사용자의 웹 Browser로 보내고나면, 요청 -응답 주기가 끝나게 된다.
여기서! 클로저란???
클로저(closure)는 익명 함수의 PHP 버전이다. 클로저는 객체로 전달하거나 변수에 할당하고, 다른 함수나 메서드에 파라미터로 전달하거나 직렬화(Serialization)할 수 있는 함수이다.
cf) 익명함수를 보니, node.js를 할 때가 생각난다.
var func1 = ()=>{
} Arrow function을 써서 사용했었는데...!!
간단한 웹사이트용 라우트 예제
Route::get('/',function(){ return view('welcome') }); // Route::get('about',function(){ return view('about'); }); // Route::get('products',function(){ return view('products'); }); // Route::get('services',function(){ return view('services'); });Static 호출??
Route::get('',function(){})과 같이 호출하는데 이는 php의 특징이다. 이는, 라라벨의 Facade 기능을 사용한 서비스의 위치를 식별하는 것이다.
만약, Facade를 사용한 스태틱 호출 형태를 선호하지 않는다면,$router->get('/',function(){ return 'Hello, World!'; });처럼 사용할 수 있다.
출처
https://loy124.tistory.com/368 http method
https://ko.wikipedia.org/wiki/%EB%A3%A8%ED%94%84%EB%B0%B1 루프백
Laravel: Up & Running: A Framework for Building Modern PHP Apps O'REILLY 참고
https://meetup.toast.com/posts/92 REST
