Aprendizagem de anotação personalizada do Spring: https://blog.csdn.net/qq_34582693/article/details/88943120
Aprendendo os princípios básicos da JVM: https://blog.csdn.net/qq_34582693/article/details/79513676
Aprendizagem multiencadeada JAVA: https://blog.csdn.net/qq_34582693/article/details/79843258
Aprendizagem do Spring framework: https://blog.csdn.net/qq_34582693/article/details/86166527
Bem-vindo atenção, bem-vindo para discutir.
Antes de usar o Rest, deixe-me falar sobre os benefícios do método de solicitação Rest. Primeiro, é URI orientado a recursos, ou seja, o caminho da solicitação http. O Rest estipula que cada camada do URI só pode usar substantivos sem verbos, que são mais propícios à transmissão do que as solicitações get tradicionais. A estabilidade dos dados, o processo de operação dos dados não será facilmente visto pelas pessoas, também é conveniente para o desenvolvimento da equipe e vários URIs são claros à primeira vista;
Em seguida, use um método de solicitação fixa para executar várias operações nos recursos do URI. Normalmente usados são:
GET: query;
POST: add;
PUT: modify;
DELETE: delete;
solicitações de http em conformidade com este estilo, chamamos de RestFul;
Isso também envolve um conceito chamado idempotência, ou seja, quantas operações no URI retornarão o mesmo resultado.
Como o POST é novo, não é idempotente em teoria e outros métodos são idempotentes.
A seguir está o combate real, arquitetura de boot-boot, escreveu uma classe de teste, usando postman para teste de solicitação http:
@RestController
public class UserController { @RestController: esta é a anotação de spring-boot: contém
@Target (ElementType.TYPE)
@Retention (RetentionPolicy.RUNTIME)
@Documented
@Controller
@ResponseBody
mostra que não é apenas um controlador, mas também suporta o estilo de descanso
@PathVariable: corresponde automaticamente a solicitação de resto ao parâmetro com o mesmo nome
@ModelAttribute: reúne automaticamente os parâmetros de formulário solicitados em objetos
@RequestBody: reúne automaticamente os parâmetros json solicitados em objetos
Comece a avaliar abaixo:
Investigar:
/ **
- operação de estilo repousante
- @param name
- @return
* /
@RequestMapping (value = "/ xx / {name}", method = RequestMethod.GET, makes = "application / json; charset = UTF-8")
private String query (@PathVariable String name) { String result = "Consultar um resultado denominado" + nome + ""; resultado de retorno; }
Adicionado:
/ **
- Adicionar
- usuário @param
- @return
* /
@RequestMapping (value = "/ xx", method = RequestMethod.POST, makes = "application / json; charset = UTF-8")
private String add (@RequestBody User user) { String result = "Add A resultado denominado "+ user.getUsername () +" e senha "+ user.getPassword () +"; resultado de retorno; }
excluir:
/ **
- excluir
- @param nome de usuário
- @return
* /
@RequestMapping (value = "/ xx / {username}", method = RequestMethod.DELETE, makes = “application / json; charset = UTF-8”)
private String del (@PathVariable String username) { String result = “删除 一个 名为” + nome de usuário + “的 结果”; resultado de retorno; }
Modificação:
Por que eu disse modificação no final, porque existem armadilhas!
/ **
- modificar
- usuário @param
- @return
* /
@RequestMapping (value = "/ xx", method = RequestMethod.PUT, makes = "application / json; charset = UTF-8")
private String edit (@RequestBody User user) { String result = "Modify one O resultado denominado "+ user.getUsername () +" e senha "+ user.getPassword () +"; return result; } Descobrimos que os parâmetros de post e put mudaram de @ModelAttribute para @RequestBody;
Isso porque eu imitei o envio do formulário [modificado] através do carteiro no início, o parâmetro de fundo é nulo, Baidu, muitos mestres, alguns dizem que o spring não suporta pedidos de colocação, alguns dizem que os formulários do formulário não suportam PUT e DELETE, e alguns dizem Precisa de um filtro.
Também experimentei um por um e finalmente descobri que ainda é possível usar json:
Com essas conclusões, finalmente mencionei uma criança:
PATCH:
Teoricamente falando, a atualização feita por PUT é para todo o objeto. Geralmente, todo o objeto é transmitido para o fundo para a modificação geral. Se eu quiser alterar apenas um campo, tenho que fazer isso também, o que é um desperdício de largura de banda, então PATCH aparece: [Atualização parcial];
Algumas pessoas dizem que PUT é idempotente e PATCH não é idempotente;
PUT coloca um arquivo ou recurso em um URI específico e, por acaso, está nesse URI. Se houver um arquivo ou recurso no URI, PUT substituirá o arquivo ou recurso. Se não houver arquivos ou recursos, PUT cria um. PUT é idempotente, mas o paradoxo é que a resposta PUT não pode ser armazenada em cache.
O POST envia dados para um URI específico e espera que o recurso nesse URI processe a solicitação. Nesse ponto, o servidor Web pode determinar como processar os dados no contexto de recurso especificado. O método POST não é idempotente, mas contanto que o servidor defina os cabeçalhos Cache-Control e Expires apropriados, a resposta POST pode ser armazenada em cache.