Home/ Questions/Q 8630675
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T09:06:32+00:00

I’m trying to develop a simple web service using Recess , which is a

  • 0

I’m trying to develop a simple web service using Recess, which is a web framework aimed at being simple to use and being inherently RESTful. I’ve found it to be very easy to use the CRUD functionality in Recess. I’ve created a model with its backend in a MySQL database, and found that a REST API was already available for use.

That’s great, but the problem is that I have no user authentication, which pretty much renders the really nice functionality I described above completely useless. In a real world application, authentication would be needed for accessing user-specific resources. For example, let’s say I’m developing a simple “to-do” application (which I’m not, by the way). The user has no interest in what other people put in their to-do lists, so the service needs to identify who the user is, so as to provide the correct data. Also, the user should not be allowed to read, delete or update other peoples’ resources.

This is done normally with a login system. But for a REST API, how is the user authenticated? Does the client need to provide the user’s credentials (like a username and password) every time a request is made? How can that be avoided? Normally, one can use cookies, but this is probably not good practice, since not all clients are necessarily web browsers. But if we are to emulate the functionality of cookies, how do we transmit the “cookies'” contents (normally, this is done in the HTTP header)? And finally, how can I integrate a solution to these problems in Recess’s built-in REST functionality?

As you can see, I’m fairly new to developing REST APIs, so any suggestions and pointers would be welcome.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    RESTful systems leverage existing technologies already available rather then re-implement them. And since HTTP already contains authentication support in the form of Basic Authentication, you should just re-use that. It’s a widely-supported mechanism for clients to transmit their credentials.

    And yes, the client should send their credentials with each request. Cookies are for human clients who don’t like to type in their password repeatedly, and that’s not the case here. Cookies imply session statefulness on your server and that can make scalability very difficult.

    There are probably a hundred questions on this site about RESTful authentication. I’d encourage you to search for and read the more popular ones.

    • 0