Reply content:
Landlord should have a basic understanding of rest, so the basic concept I will not repeat, only to say the landlord more confused points
resources are not directly mapped to underlying storage objects or program model
Not that you have the user table and the role table, you must design the corresponding resources.
In fact, the relationship between a restful resource and the underlying storage service is similar to the relationship between tables and views within a relational database, which is a collection of relationships formed by combining multiple tables according to the actual query.
Whether your storage service is a relational database or a NoSQL database or even a text file, it is the same for clients accessing resources.
So create a user, set their roles at the same time, can complete directly with Post/user
Create a new user with Foo and bar two roles
Post/user
{name: (string), passwd: (String), roles: [' foo ', ' Bar ']}
If the response header can contain the following two best
Respond with 201 status to notify the new resource URL with location
http/1.1 201 Created
Location:/USER/1
---------------------------------------------------------
Modify the user's role to Foobar
Put/user/1
{roles: [' Foobar ']}
---------------------------------------------------------
To modify a user's password
Put/user/1
{passwd: (String)}
As for/userrolerelation such a smaller size than the resources, I suggest not, the granularity of the resources should be first coarse and thin, according to the evolution of business follow-up and the actual need to consider whether to abstract more granular resources, in the beginning is too thin, any operation will be decomposed into multiple network IO, And the complexity of the system is easy to make relatively high.
Mapping specific database tables to resources, and then the crud action to the Get/post/put/delete, both silly and insecure, originally these things are for business services, because the business needs exist, the result is not around the abstraction of business design, which is the cart before the horse.
The correct idea should be, forget what database and program model, only from the point of view of the HTTP, according to the business, need to design what resources (URLs), get/post when to accept and respond to which parameters, the finalization of these, then from the database and program model to consider how to fit. Lynda has a video tutorial to teach you how to design a restful API, or a good
Effective Design of RESTful APIs
From the existing framework, the operation of resources is generally mapped to object methods. The design of resources is coarse-grained, rather than the design of resources from the underlying database. Use a mature framework to complete restful design, typically a resource-object-relational database that contains a two-layer mapping. Upstairs, the design of RESTFUL systems should be based on business, not from the underlying database.
First think about the business scope and function of your system, then classify the database crud into business operations and consider how the database fits into the business process.
