SpringMVC開発RESTfulインタフェース
4802 ワード
コンセプト:
RESTとは?
RESTは、Representational State Transferの略.「表現層状態変換」と訳され、restfulはインタフェース設計スタイルであり、プロトコルではなく、通常HTTPプロトコルに基づいている.
なぜこのようなスタイルが必要なのでしょうか.
RESTfulのポイントの一つは、統一されたインタフェース命名規則である.
各開発者には異なるインタフェーススタイルがあるかもしれませんが、最も一般的なのはgetUserInfo、deleteUserInfoなどに似ています.しかし、これは純粋に開発者一人一人の習慣と関係があり、複数人が共同で開発すると問題が発生する可能性があり、特にフロントバックグラウンドが分離すると、フロントスタッフは異なるurlを大量に記入してデータを要求しなければならない.
RESTfulスタイル:
restはすべてのURIを1つの資源と見なして、これは1つの概念で、実際には1つのピクチャで、1つの記録で、1組の記録ですべてできます;各リクエスト・メソッドは、通常、次の4つのリソースに対する操作に対応します. GET取得リソース PUT更新リソース POST送信リソース DELETE削除リソース idが1のユーザデータをリソースと見なすと、フロントでこのリソースを操作するときに、このリソースを特定できるリクエストアドレスをサーバに送信します.たとえば、次のようにします.http://localhost:8080/SSMDemo/user/1,URIでリソースを見つけた後,サーバにこのリソースに対してどのような操作を行うか,HTTPのリクエスト方法を教える.GETのように
簡単に言えば、RESTfulはURIでリソースを位置決めし、要求方法で実行する操作を定義する.
現在、RESTfulに完全に従って設計されているサイトは多くありません.アマゾンはこのようなスタイルを最初に採用したサイトの一つです.そのURLはこのようになっています.
ステータス制約なしでサーバの変化はクライアントに対して可視ではなく、2回の連続した要求の中で、クライアントは同じサーバに依存せず、サーバにより良い伸縮性を備えさせる.
RESTfulがシステムに与えるメリット:
開発の複雑性を低減し、システムの伸縮性を高め、インタフェースをより規範化する.
URIとURL:
URLは統合リソースID(1つのリソースを一意に識別できる限りURIと呼ぶ)
URLは統合リソースパス
URLはURIの一種に属する
SpringMVCのRESTful
RESTfulの変化は,要求アドレスの処理と,要求メソッドの定義にあることがわかる.
私たちには2つのことがあります. URLからいくつかのパラメータ を取得する必要がある.は、同じインタフェースの異なる要求方法が対応する動作 を完了することを可能にする.
ケース:カリキュラムリソースを操作するRESTfulインタフェースを設計する
コントロールの作成
@PathVariableはurlからパラメータを取得するために使用され、RequestMappingに{パラメータ名}を追加します.プレースホルダとして、パラメータ名はメソッドのパラメータ名と同じである必要があります.異なる場合は@PathVariableにvalueを追加できます(通常はそうする必要はありません).
インタフェーステストはpostman macを使用してpawを使用することを推奨します.
また、実際の開発では、認証のためにフロントにユーザートークンを渡す必要があります.ブロッキングによって実現することができる.
補足:
Tomcatはgetとpostのパラメータのみを解析します.SpringMVCでPUTまたはDELETEが使用され、フォームコミットが使用されている場合は、パラメータを取得できません.Tomcatにパラメータ接続なしでrequestに配置する必要があります.SpringMVCはtomcatがput/deleteのパラメータを解析してrequestに入れるのを支援するフィルタを提供します.構成方法は以下の通りです.
web.xml:
SpringMVCはリクエストボディから直接jsonデータを取得し、requestを通過しないため、上記の問題はjsonインタラクションを使用する場合には発生しません.
うるさい:ページ上のフォームがPUT/またはDELETEリクエスト方式を使用している場合は、webで必要です.xmlに上のフィルタを加える.
RESTとは?
RESTは、Representational State Transferの略.「表現層状態変換」と訳され、restfulはインタフェース設計スタイルであり、プロトコルではなく、通常HTTPプロトコルに基づいている.
なぜこのようなスタイルが必要なのでしょうか.
RESTfulのポイントの一つは、統一されたインタフェース命名規則である.
各開発者には異なるインタフェーススタイルがあるかもしれませんが、最も一般的なのはgetUserInfo、deleteUserInfoなどに似ています.しかし、これは純粋に開発者一人一人の習慣と関係があり、複数人が共同で開発すると問題が発生する可能性があり、特にフロントバックグラウンドが分離すると、フロントスタッフは異なるurlを大量に記入してデータを要求しなければならない.
RESTfulスタイル:
restはすべてのURIを1つの資源と見なして、これは1つの概念で、実際には1つのピクチャで、1つの記録で、1組の記録ですべてできます;各リクエスト・メソッドは、通常、次の4つのリソースに対する操作に対応します.
簡単に言えば、RESTfulはURIでリソースを位置決めし、要求方法で実行する操作を定義する.
現在、RESTfulに完全に従って設計されているサイトは多くありません.アマゾンはこのようなスタイルを最初に採用したサイトの一つです.そのURLはこのようになっています.
https://www.amazon.cn/gp/product/B00MCW8R1S
RESTfulの無状態性:ステータス制約なしでサーバの変化はクライアントに対して可視ではなく、2回の連続した要求の中で、クライアントは同じサーバに依存せず、サーバにより良い伸縮性を備えさせる.
RESTfulがシステムに与えるメリット:
開発の複雑性を低減し、システムの伸縮性を高め、インタフェースをより規範化する.
URIとURL:
URLは統合リソースID(1つのリソースを一意に識別できる限りURIと呼ぶ)
URLは統合リソースパス
URLはURIの一種に属する
SpringMVCのRESTful
RESTfulの変化は,要求アドレスの処理と,要求メソッドの定義にあることがわかる.
私たちには2つのことがあります.
ケース:カリキュラムリソースを操作するRESTfulインタフェースを設計する
コントロールの作成
package com.kkb.controller;
import com.kkb.pojo.Course;
import com.kkb.service.CourseService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;
@RestController
public class RESTCourseController {
@Autowired
CourseService service;
//
@RequestMapping(value = "/course",method = RequestMethod.GET)
public List getCourseList(){
System.out.println("getCourseList");
return service.selectCourses();
}
// id
@RequestMapping(value = "/course/{id}",method = RequestMethod.GET)
public Course getCourse(@PathVariable Integer id){
System.out.println("getCourse");
System.out.println(" :"+id);
return service.selectByID(id);
}
//
@RequestMapping(value = "/course",method = RequestMethod.POST)
public String addCourse(@RequestBody Course course){
System.out.println("addCourse");
System.out.println(" :"+course);
service.insertCourse(course);
return "{\"msg\":\"success\"}";
}
// id
@RequestMapping(value = "/course/{id}",method = RequestMethod.DELETE)
public String deleteCourse(@PathVariable Integer id){
System.out.println("deleteCourse");
System.out.println(" :"+id);
service.deleteCourse(id);
return "{\"msg\":\"success\"}";
}
// id
@RequestMapping(value = "/course",method = RequestMethod.PUT)
public String updateCourse(@RequestBody Course course){
System.out.println("updateCourse");
System.out.println(" :"+course);
service.updateCourse(course);
return "{\"msg\":\"success\"}";
}
}
@PathVariableはurlからパラメータを取得するために使用され、RequestMappingに{パラメータ名}を追加します.プレースホルダとして、パラメータ名はメソッドのパラメータ名と同じである必要があります.異なる場合は@PathVariableにvalueを追加できます(通常はそうする必要はありません).
@RequestMapping(value = "/course/{cid}",method = RequestMethod.GET)
public Course getCourse(@PathVariable("cid") Integer id){
System.out.println("getCourse");
System.out.println(" :"+id);
return service.selectByID(id);
}
インタフェーステストはpostman macを使用してpawを使用することを推奨します.
また、実際の開発では、認証のためにフロントにユーザートークンを渡す必要があります.ブロッキングによって実現することができる.
補足:
Tomcatはgetとpostのパラメータのみを解析します.SpringMVCでPUTまたはDELETEが使用され、フォームコミットが使用されている場合は、パラメータを取得できません.Tomcatにパラメータ接続なしでrequestに配置する必要があります.SpringMVCはtomcatがput/deleteのパラメータを解析してrequestに入れるのを支援するフィルタを提供します.構成方法は以下の通りです.
web.xml:
HttpPutFormContentFilter
org.springframework.web.filter.FormContentFilter
HttpPutFormContentFilter
/*
SpringMVCはリクエストボディから直接jsonデータを取得し、requestを通過しないため、上記の問題はjsonインタラクションを使用する場合には発生しません.
うるさい:ページ上のフォームがPUT/またはDELETEリクエスト方式を使用している場合は、webで必要です.xmlに上のフィルタを加える.