Both approaches can be considered RESTful, provided you do not break the REST constraints defined in the chapter 5 of Roy Thomas Fielding’s dissertation: Client-server Stateless Cache Uniform interface Layered system Code-on-demand I cannot see major pitfalls in both approaches, but I would prefer the Approach B over the Approach A: the URLs are shorter, … Read more
Based on HTTP’s definition of PUT, your first request is overwriting the list of players with a new list that contains just one player name. It is not adding to the list of players. The second option does not really make much sense to me. Doing PUT without a body is not really consistent with … Read more
Configure the routes as below. The {param} is optional (use if you need): routes.MapHttpRoute( name: “childapi”, routeTemplate: “api/Parent/{id}/Child/{param}”, defaults: new { controller = “Child”, param = RouteParameter.Optional } ); routes.MapHttpRoute( name: “DefaultApi”, routeTemplate: “api/{controller}/{id}”, defaults: new { id = RouteParameter.Optional } ); Then call the child APi as /api/Parent/1/child The parent can be called simple … Read more
In Spring 3.1 a preferred way to control this behaviour is to add a RedirectAttributes parameter to your method: @RequestMapping(“save/”) public String doSave(…, RedirectAttributes ra) { … return “redirect:/success/”; } It disables addition of attributes by default and allows you to control which attributes to add explicitly. In previous versions of Spring it was more … Read more
Since POST is an “append” operation, it might be more Englishy to POST to /products, as you’d be appending a new product to the existing list of products. As long as you’ve standardized on something within your API, I think that’s good enough. Since REST APIs should be hypertext-driven, the URI is relatively inconsequential anyway. … Read more
The following urls: http://example/foo http://example/foo/ Are NOT the same url. Caches will store them separately. So in that sense there is a real difference. Normalizing URLs will not strip them. Every URI (ending with slash or not) will point to a resource. As far as I know there is no specific recommendation to use either. … Read more
HEAD is the most effecient for existence checks: HEAD /users/{username} Request a user’s path, and return a 200 if they exist, or a 404 if they don’t. Mind you, you probably don’t want to be exposing endpoints that check email addresses. It opens a security and privacy hole. Usernames that are already publicly displayed around … Read more
Some snippets from the REST API Design Rulebook about different resource types: Document A document resource is a singular concept that is akin to an object instance or database record. Example: http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet Collection A collection resource is a server-managed directory of resources. Clients may propose new resources to be added to a collection. However, it … Read more
This is well documented in the project: https://github.com/domaindrivendev/Swashbuckle.AspNetCore#include-descriptions-from-xml-comments Include Descriptions from XML Comments To enhance the generated docs with human-friendly descriptions, you can annotate controller actions and models with Xml Comments and configure Swashbuckle to incorporate those comments into the outputted Swagger JSON: 1 – Open the Properties dialog for your project, click the “Build” … Read more
@PathVariable and @PathParam both are used for accessing parameters from URI Template Differences: As you mention @PathVariable is from spring and @PathParam is from JAX-RS. @PathParam can use with REST only, where @PathVariable used in Spring so it works in MVC and REST.