Design e boas praticas de apis com CSharp
Transferir como PPTX, PDF2 gostaram716 visualizações
O documento apresenta boas práticas para o desenvolvimento de APIs com C#, focando em consistência, verbos HTTP, status codes, endpoints, versionamento, documentação e performance. As principais recomendações são: usar verbos como GET e POST de forma consistente, escolher status codes apropriados, nomear endpoints com recursos e ações, documentar a API e usar técnicas como gzip e async/await.
![[ATC] Testando sua API com HTTPARTY e Rodando em um CI](https://cdn.slidesharecdn.com/ss_thumbnails/atctestandosuaapi-171113033544-thumbnail.jpg?width=560&fit=bounds)
![REST-fuuuu - Boas práticas RESTful [PHPeste 2017]](https://cdn.slidesharecdn.com/ss_thumbnails/rest-fuuuu-toptal-171018155515-thumbnail.jpg?width=560&fit=bounds)
![Como gerenciar e manter minha equipe engajada [Avance 21]](https://cdn.slidesharecdn.com/ss_thumbnails/comogerenciaremanterminhaequipeengajada-211009151249-thumbnail.jpg?width=560&fit=bounds)
Mais conteúdo relacionado
Semelhante a Design e boas praticas de apis com CSharp (20)
Mais de Rodolfo Fadino Junior (20)
Último (15)
Design e boas praticas de apis com CSharp
- 1. @RODOLFOFADINO Design e boas práticas de APIs com C# #VSSUMMIT
- 4. SEJA CONSISTENTE EM SUA API (STATUS CODE, HTTP VERBS, ENDPOINTS, ERROS) Do: Use GETs para retornar dados. Use PUTs/POSTs para alterar dados. Use a mesma estrutura de endpoints em toda api. Escolha alguns status code para utilizar e manter a consistencia em toda api. Don’t: Use status code de uma maneira não esperada. Se voce irá retornar uma lista de posts, não retorne um 404 caso nao exista nenhum post, retorna uma lista vazia. Use GETs para alterar dados ou PUTs/POSTs para somente retornar dados. Mensagens de erro para descrever condições.
- 5. ENDPOINTS:RECURSOS/VERBOS GET /posts GET /posts/123 POST /posts versus GET /getAllPosts GET /getPostById POST /createPost
- 6. AÇÕES DIFERENTES DE UM CRUD Curtir um post PUT /posts/:id/like DELETE /posts/:id/like Favoritar um post PUT /posts/:id/star DELETE /posts/:id/start
- 7. VERBOS HTTP GET /posts - Lista de posts GET /posts/12 - Post especifico POST /posts - Cria um novo post PUT /posts/12 - Atualiza o post #12 PATCH /posts/12 - Atualiza parcialmente o post #12 DELETE /posts/12 - Remove o post #12
- 9. STATUS CODE 200 OK - Resposta de sucesso de um GET, PUT, PATCH or DELETE. Pode ser utilizado para um POST que não crie uma entidade. 201 Created - Resposta para um POST que cria uma entidade. Poe ser combinado com um header location 204 No Content - Resposta de uma request que teve sucesso, que nao possua retorno (DELETE request) 304 Not Modified - HTTP caching headers 400 Bad Request - Request mal formada 401 Unauthorized - Autenticação inválida. 403 Forbidden - Quando a autenticacao funciona, mas o usuário nao tem acesso ao recurso. 404 Not Found - Quando aquele recurso nao existe 405 Method Not Allowed - Quando um verbo HTTP está sendo utilizado por um usuario que não tem a permissão (DELETE por exemplo) 429 Too Many Requests - Rate limiting
- 10. VERSIONAMENTO
- 11. SSL SEMPRE
- 12. DOCUMENTAÇÃO
- 14. GZIP NGINX IIS OU =>
- 15. DTOS
- 16. VALIDAÇÃO
- 18. ASYNC/AWAIT
- 19. LINKS rodolfofadino.com docs.asp.net vinaysahni.com/best-practices-for-a-pragmatic-restful-api medium.com/@schneidenbach/