I have a logout endpoint to make the current user token invalid.
With this I had a question: Which HTTP verb should I use to log out?
I have a logout endpoint to make the current user token invalid.
With this I had a question: Which HTTP verb should I use to log out?
Just review the recommendations defined in RFC 2616, section 9, Method Definitions .
DELETE
The DELETE method requests that the source server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client can not be guaranteed that the operation has been carried out, even if the status code returned from the originating server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.
A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has been enacted, or 204 (No Content) does not include an entity.
If the request passes through the cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
Since access to the application is a feature identified by the token and you want to delete this token , disabling access, then the DELETE method is the appropriate
Free Translation:
The DELETE method requests that the source server exclude the resource identified by the Request-URI . This method can be replaced by a human intervention (or other means) on the source server. The client can not guarantee that the operation has been performed, even if the status code returned from the source server indicates that the action completed successfully. However, the server MUST NOT indicate success unless, at the time the response is given, you want to delete the resource or move it to an inaccessible location.
A successful response MUST be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted or 204 (No Content) if the action was enacted, but the response does not include an entity.If the request goes through a cache and the request URI identifies one or more entities that are currently cached, these entries MUST be treated as obsolete. Responses to this method are not cached.
Personal note:
If you have a full domain of API development, that is, you have developed both the API and the client, you can rely on the 200 answer, moving slightly from the above recommendation, because in the API you can return the 200 only when the resource is properly deleted. The recommendation defines that the response should not be trusted especially when you are using a third-party API.
Recommended readings
I would say that an interesting method to use would be DELETE
(based on an API I know from IBM), because when you do the authentication you create an access Token and when you go to disconnect this Token can not be more used then I think DELETE
describes well:
DELETE /api/1.0/token HTTP/1.1
The response of status
may vary slightly depending on whether the token exists or not, as link the response status should be:
200 (Ok)
if you return a description in the body 201 (Accepted)
if the action has not yet been completed (probably if it is checked later) 204 (No Content)
if the action does not have a response in the body Note: If the request goes through a cache and the request URL identifies one or more cached entities, these MUST entries be treated as deprecated . Responses to this method should not be cached.