For example, if there were User and Product models,
when each is in a user has_many products, product belongs_to user relationship.
I want to shorten the URL if it's a web app, so I'll use the URL structure /users/:user_id/products: Instead of retrieving user information from the user_id parameter,
I usually design user information like a URL with only products by letting cookies chew it.
However, when I tried to create an API for iOS using a gem called grape, I felt it was not appropriate to obtain user information through cookies, so I thought about changing the URL structure of the API.
So I would like to ask if the URL structure of rails as my web application is bad or if the URL structure of API should be designed for this purpose.This is the first time that we are developing an API for iOS...
Thank you for your cooperation.
In principle, it is against the REST principle that the cookie should have the information of user instead of the URL /users/:user_id/products and change the return of /products based on it.As a result, the stateless client cannot identify the user.
If the user information stored in the cookie is the credentials, and /products only have to deal with resources associated with "Authenticated User (=me), and you don't have to deal with product of non-authenticated users (=others), then the API should identify the user.
If the credentials are not stored in the cookie, for example, if /user/foo is displayed, foo is stored in the cookie, and /products uses that information to process it, then the URL /users/:user_id/products is better.
In the case of APIs, users are often authenticated by OAuth and issued Token, and then embedded in the header for each access to manage their sessions.
So there is a difference between cookies and tokens, but they are basically the same.It is normal to identify the current_user from Token and omit /user/:user_id.
© 2024 OneMinuteCode. All rights reserved.