RestAPI, routes, relationships, models?

0 like 0 dislike
I welcome the participants of the toaster!

If you take for example a relationship of posts and pictures (OneToMany):

Posts title content Images src post_id

As would be logically correct to organize business logigu and routes api on the backend, when creating a new post, for example.
Seems to me this version of the script:

The user fills in the title field and the content on the client and loads the necessary images, the client making the POST request on the route /images/uploads/ Content-Type: multipart/form-data, json gets successfully added images, something like this:

{ "status": "success", "images": [ { "id": 1, "src": "/uploads/foo.png" }, { "id": 2, "src": "/uploads/bar.png" } ] }

The client displays these pictures as prevthe.
After that, the User clicks the submit button, the handler, the client serializes the title and content data and sends the POST request to /api/posts/ if data is valid then the response goes something like:
{ "status": "success", "id": 1 }

The client accepts the id added post and makes another request to associate the post with pictures, assume the method would PATCH or PUT to the route /api/posts/1/images/, because pictures have been uploaded to the server and included in the database in the request body can be sent that sent us /images/uploads/.
There is no problem when such a simple scheme, and if you want to add to this relationship the posts to the tags also need to ensure the data validity of each model is that the post was created correctly.
Or is it better to send the entire data on the post title, content, images, tags, ...?
Even had the idea to design the form dynamically on the client and send as form and not as json but getting json to the status of a completed request, but it will not be restful, but probably just a json api.
In General who makes as I'd love to hear the pros and cons.
by | 106 views

1 Answer

0 like 0 dislike
In reste there's no spec, there is a thesis with which it all went, and a bunch of different variations of formats that promote for use, for example, as one of the formats offers to solve your problem: In a project so convenient, in a way, it is not convenient, some need something else.
Ful or ful, this is not important, and in the original json no it was not like he didn't even been invented. So do what is comfortable, give and take format that's easy(almost all frameworks out of the box correctly handle json,xml, form data), and all these arguments about reste, it's like talking about what the PLO.

Related questions

0 like 0 dislike
1 answer
0 like 0 dislike
3 answers
0 like 0 dislike
1 answer
0 like 0 dislike
1 answer
0 like 0 dislike
1 answer
110,608 questions
257,187 answers
40,796 users