Error:rendered manifests contain a resource that already exists.unable to continue with install:could not get information about the resource:secret "gitlab-runner-gitlab-runner"is forbidden:user"system:node:staging.online"cannot get resource "secrets"in api group in the namespace default no relationship between node staging.online and this objects
Related
According to JSON API V1 specification and its recommendations, I know the URLs for collection of resources should be something like /photos. And the URL for reading, updating, or deleting a single resource that already exists in the database should be something like GET, PATCH, DELETE /photos/:id, for example.
But are there any URL requirements for rendering JSON data for resources to be created (i.e. the resource does not exist in DB yet and therefore it doesn't have id) yet. I know this is allowed in terms of the response data as section 5.2 says
Exception: The id member is not required when the resource object originates at the client and represents a new resource to be created on the server.
However, can the URL for rendering such a new object be like photos/new? As I'm using Ruby on Rails on the backend, photos/new is pretty typical.
Thanks!
The JSON:API specification is agnostic about URL design. But it defines how given URLs should be used. For creation of resources the URL, which represents a collection of resources of that type should be used:
A resource can be created by sending a POST request to a URL that represents a collection of resources.
https://jsonapi.org/format/#crud-creating
If you use /photos URL for a collection of photos, you should support creating another photo resource on that endpoint.
The server must assign an ID to a resource on creation unless client-generated IDs are used. It should also inform the client about the URL representing the newly created resource both through self link of the resource as well as Location HTTP response header. Going forward a client should use that URL to fetch the resource.
However, can the URL for rendering such a new object be like photos/new?
I'm not sure what you mean. A resource, which has not been created yet, can not be fetched from a REST API.
The term "render" is not that common for REST APIs. Do you refer to responding with a JSON representation of a resource as "rendering"? In this case a REST API cannot "render" the resource before it has been created by the client.
URLs of clients are independent from the URLs used by a REST API. A client could render a form to create a new resource on end-user facing URL /photos/new, while using the /photos URL of the REST API to create that resource.
Usually to create new object POST is using
You just pass resource attributes with request body. And you doesn't pass id
Modified example from your link
{
"type": "photos",
// no id here
"attributes": {
"title": "Rails is Omakase"
}
}
And path for such request is /photos
In monolithic Rails app /new is just page to create some resource, you don't need such GET-route in the JSON API
I'm using the default resource in my routes.rb to add clients to my applications via resources :clients. But I'd like to be able to access that new page of clients via a group_id aswell.
So I want access like /clients/new/ and as clients/new/1/ or something.
I've tried adding my group to my path like new_client_path(group) but it gives me a .3 and showing the params shows that the 3 is called 'format'.
So, Long story short: How can I get a group_id to my clients/new/ page?
Thanks in advance
You can use nested resources:
resources :groups
resources :clients
end
Now to get new client form with group id set you just need:
new_group_client_path(group)
assuming, of course, that group variable holds an Group instance.
If you don't want to use nested resources, you can set group_id this way
new_client_path(group_id: group)
Consider the following snippet from router.rb
resource :user do
namespace :settings do
resource :access_filter
end
get 'settings'
end
This generates the URL's I want (user/settings/access_filter), but it produces an undesired directory structure and some long url helpers.
In this case, the helper becomes new_user_settings_access_filter and I would prefer just to have new_access_filter. And Rails expects the AccessFiltersController to reside in a module named Settings.
I would like a way to keep a flat directory structure, a flat url helper structure, but a "nested" URL structure. As long as no parameters are neccessary, I don't think my controllers and views needs to know that access filters are nested under the user model and I would like to retain the opportunity to move them to say options/access_filter without breaking the site.
Sugggestions on how to get there would be appreciated.
If you only want to prefix the path, you could avoid the nesting and any hassle involved by using a separate scope. Organizationally, this seems to make sense as well, since you effectively want to decouple the access filter routes from user.
scope "user/settings" do
resource :access_filter
end
# then if you wanted to change it later, it's simply
scope "options" do
resource :access_filter
end
scope is a lower level function actually used by namespace. It's far more flexible, and allows you to decorate paths without changing the controller lookup and route names, among other things.
Dumb question but I have some lingering confusion of what, exactly, a "resource" is in Rails. The term is used everywhere but I get a funny feeling it might be being used rather loosely. It's referenced in the model, the controller and, quite literally, in routes.rb.
Is it the specific route? For example, map.resources maps the 7 RESTful "resources". So an example of one resource would be the call to, say, the index action of a particular class's controller?!?
Is it a reference to the whole page/object being retrieved? or perhaps, more narrowly, a database table? or the row being retreived?
Is it something else?
Anyway, hopefully someone can set me straight...
Any object that you want users to be able to access via URI and perform CRUD (or some subset thereof) operations on can be thought of as a resource. In the Rails sense, it is generally a database table which is represented by a model, and acted on through a controller.
For example, you might have a User resource (with a users table in your DB). This is represented by a User model, is mapped to users_controller with map.resources :users (which then generates routes like /users (a collection of User resources) and /users/1 (a specific User resource).
You act upon those resources by using the appropriate HTTP method when making calls to those resources. POST to the resource collection (/users) creates a new record; GET retrieves a list of resources (/users) or a specific user (/users/1). PUT updates a specific user (/users/1/), and DELETE destroys that user. The URLs are the same, but the result (and controller action) may be different based on the HTTP verb. The idea, though is that /users/1 always means "I'm interacting with the User that has ID #1", regardless of the action.
Here's a good article discussing how most developers think that "Resource" is synonomous with the database table, the argument, I guess, being that mapping to the resource is mapping the controller to that database table (or, with ActiveResource, to another REST url).
Basically, I think a "resource" is "persisted data." map.resources maps the 7 RESTful actions to a particular suite of persisted data.
But I haven't thought about it too much in depth. Good question!
I think they probably mean it in the general web sense, i.e., Resource (Web):
the referent of any Uniform Resource Identifier
I don't think it has anything to do with database tables.
open your model folder, that is a hint of what resources you have!
example: users, pictures, comments...
A lot of people here say that resources refer to the database tables you have. It might be true sometimes but not necessarily true always. I could give you a lot of examples where you don't have a corresponding table in your database for a particular resource. Hence asssociating it with tables is rather wrong.
I would define a resource as a route which maps to related requests. So instead of declaring separate routes for the actions you want to do you can simply declare them using a resourceful route.In Rails, a resourceful route provides a mapping between HTTP requests and URLs to controller actions.
So say you define resources :users in config/routes.rb. You can now use a number of helpers to the controllers in your application like edit_user_path which returns users/edit .
Here's a good link: https://api.rubyonrails.org/v5.2.1/classes/ActionDispatch/Routing/Mapper/Resources.html
Which basically says: Resource routing allows you to quickly declare all of the common routes for a given resourceful controller. Instead of declaring separate routes for your index, show, new, edit, create, update and destroy actions, a resourceful route declares them in a single line of code:
resources :photos
I'm working on building the URLs for my REST API before I begin writing any code. Rails REST magic is fantastic, but I'm slightly bothered the formatting of a URL such as:
http://myproject/projects/5
where Project is my resource and 5 is the project_id. I think if a user is looking to retrieve all of their projects, then a respective HTTP GET http://myproject/projects makes sense. However if they're looking to retrieve information on a singular resource, such as a project, then it makes sense to have http://myproject/project/5 vs http://myproject/projects/5. Is it best to avoid this headache, or do some of you share a similar concern and even better - have a working solution?
Rails (3) has a lot of conventions when it comes to singular vs plural. For example, model classes are always singular (Person), while the corresponding tables are always plural (people). (For example, Person.all maps to select * from people.)
For routes, there's a concept of a singular resource as well as a plural resource. So if you did resource :account then you would get paths like /account for the default path or /account/edit for a path to a form to edit the account. (Note that Rails uses /account with a PUT method to actually update the account. /account/edit is a form to edit the account, which is a separate resource from the account itself.) If you did resources :people, however, then you would get paths like /people, /people/1, and /people/1/edit. The paths themselves indicate whether there can only be one instance of a given type of resource, or whether there can be multiple instances distinguished by some type of identifier.
I agree, go with the flow. Consider how the URL forms a hierarchy.
The root of your website is where you start to access anything.
/projects/ narrows it down to only projects, not anything else. From projects you can do lots of things, /list, /index/, /export, etc... the /id limits things even further.
At each / the scope of what do becomes narrower, and I think it makes sense.
Further programming is all about arbitrary rules. Indexs starting at 1 vs 0, and so on. Anyone working with your urls will sort things out in short order.
There are cases where a singular path to a resource is helpful. If your resource ids are non-numeric user defined names then routing clashes are possible. Example:
/applications/new --> create a new application or show user's application named new?
In this situation you can choose to limit the user input to avoid the clash, or, this can be worked around by overwriting the default Rails 3 behavior:
class ActionDispatch::Routing::Mapper
module Resources
RESOURCE_OPTIONS << :singular_resource
class Resource
def member_scope
#options[:singular_resource] ? "#{singular}/:id" : "#{path}/:id"
end
def nested_scope
#options[:singular_resource] ? "#{singular}/:#{singular}_id" : "#{path}/:#{singular}_id"
end
end
end
end
Then when specifying a new resource route:
resources :applications, :singular_resource => true
Which will generate the routes:
GET /applications
GET /applications/new
POST /applications
GET /application/:id
GET /application/:id/edit
PUT /application/:id
DELETE /application/:id