4

I'm trying to create a REST API following the HTTP method semantics but I got stuck with the DELETE method.

In my use case, the service is behind a gateway that authenticates the user. This service uses a SSO token that then is used to authenticate the user and get his details. From this point, I'm trying to make a call to my service where I use the id of the resource I want to delete as a path variable but then I don't know how to pass the id of the user for validation.

I've read many posts about the problems of adding a body to a DELETE method. I also think adding a custom header to identify the user is not the right way. Out of the options I have, I think only 2 are sensible:

  1. Issue a POST request with the user id as the body. I don't like this one because I'm basically using POST with an identified resource and because semantically sounds wrong to me.
  2. Make the request so the user id is a path variable. It would look like this. path/to/service/resourceId/{resourceId}/userId/{userId}. My problem with this one is that in the POST and PUT requests, the userId is part of the body. The API wouldn't look consistent but I guess I could still change the other 2 so the user id is also part of the url.

Any suggestions?

JavaHopper
  • 5,567
  • 1
  • 19
  • 27
Juan Vega
  • 1,030
  • 1
  • 16
  • 32

2 Answers2

2

You should use HTTP header param for passing user token.

@DELETE
@Path("/{id}")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Info deleteInfo(
        @HeaderParam("Authorization") String token,
        @PathParam("id") Long id){
}
Justinas Jakavonis
  • 8,220
  • 10
  • 69
  • 114
  • Is this still applicable when the user has been authorized already? In my case, the reason why I need the userId is to validate that the resource really belongs to him as is the end app the one that stores the data. So I think it wouldn't be authorization in this case, just validation that resource 1 belongs to user 1 and not user 2. Would that be the approach to pass clients details for validation for every app and method? Is client information like his id not valid path variable like in the case he issues a GET request to get all his resources from the app? (like path/to/app/user/{userId} ) – Juan Vega Jul 29 '16 at 09:06
  • Authentication = login + password (who you are) Authorization = permissions (what you are allowed to do) - http://stackoverflow.com/questions/6556522/authentication-versus-authorization. In my app I use POST login with JSON body which contains username and password, it returns token which is used later in header param. – Justinas Jakavonis Jul 29 '16 at 09:09
  • You are right, this is authorization of the user. I'll stick to that in this case. Thanks – Juan Vega Jul 29 '16 at 09:27
0

HTTP authentication, maybe? That's what it is for, no? See RFC 7235.

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • The authentication is done at the gateway level and the communication is done from the DMZ, that is where the gateway is, to the internal app where i need the userId.to be honest I'm not very familiar with security constraints once inside the internal company network but I guess authenticating in every microservice invoked wouldn't be very performant – Juan Vega Jul 28 '16 at 20:05