Search code examples
restapi-design

How to design RESTful API without using verbs?

EDIT:

This question has nothing to do with "will the browser work with a non-restful API" or "Token authorization headers". This question has to do with API-Design (look tags), Good practices and Authentication (/login), not Authorization (token header).

I know how to make an API, how HTTP protocol works, what is RPC and what is REST. If you read my question you might see that I understand the principles. Please read my question carefully. Dont just read the title itself and answer. You need context in order to answer.

I'm trying to design a REST API without using verbs. It's becoming more challenging, as I'm comfronting cases like Login/Authentication like controllers.

Like, how am I supposed to treat natural controllers like Authentication in a RESTful Service? I'm probably being too pedantic here, if I am please correct me, but if my API contains a request like

GET /authenticate

then it isn't considered fully restful by definition. Right? I mean, this is clearly a verb. Thus it's a RESTful+RPC API.

And if I break my REST principles for /authenticate then why should I not break my REST principles for other cases that make my life easier? Like some other business controllers for example:

GET /users (noun) REST
POST /register (verb) RPC
GET /logout (verb) RPC

This might seem like a very semantic issue, and if it does I would love you to tell me that I probably think of this in a stupid way, so I can stop caring about this. But it really seems strange to me to consider an API RESTfull when it clearly has verbs in it, so that's why I'm asking your opinion.

Otherwise, if there is a better more RESTful way to perform authentication, I would love some recommendations. As it was troublesome finding answers on the topic on Google, other than people saying "Dont use verbs in RESTful API", which is confusing in cases like this.

Disclaimer: (for not careful reviewers/readers)

This is probably not a duplicate of some other questions you might have seen, like this one How to create REST URLs without verbs?

I'm aware of what the correct solution is for this specific question, as OP asks something that can be very easily done by REST.

My issue is more semantic and not as much as a question over how to do basic REST operations like updating a user's field.

Neither this that I found is a duplicate but indeed very similar REST API Login Pattern The user asks which is an appropriate RESTful design, but he clearly does not get any answers that are answering what I'm asking. Which is the semantic (stupid or not) of "Is the design RESTful anymore if you have a /login path in your RESTful design". The answers are about Authorization, not Authentication.

Im forming this disclaimer because some of my past questions have been downvoted because they were considered duplicate, when they were actually just similar, and the downvotes were never removed even though I never got an answer back. Although, if you find an appropriate duplicate I would be really happy to accept it. Just please dont rudely throw a duplicate with the only duplicate thing being the title.

Solution

  • An example REST client and server with local login would be:

    Server API's:

    • GET /users/currentUser
      Returns a JSON document which describes the current user (display name, email address, theme preference, password expiration date, etc...)
      1. Validate username and password in Authorization: basic header, set context. If invalid, throw 401
      2. Retrieve user information, serialize, return
    • GET /todos/
      Returns a JSON document which contains all of the TODO items
      1. Validate username and password in Authorization: basic header, set context. If invalid, throw 401
      2. Retrieve To-Do items, serialize, return

    Client:

    1. Start in "Unauthenticated" state, display login UI
    2. When login button is clicked, use username and password fields to compose a Authorization: basic header and add it to the HTTP client
    3. Make a test call to GET /users/currentUser with the header to validate login info and retrieve user information. If 401, login failed - return to login UI.
    4. Save the Authorization: basic header and transition to the "Authenticated" state, display app UI
    5. Make a call to GET /todos/, format and display. If a 401 occurs, transition to "Unauthenticated" state (e.g. password changed by other client)