REST / CRUD. Am I cooking it wrong?

Introduction

REST is a very interesting method for working with objects on the server. Implementing a CRUD interface using REST is quick and easy! Today I will try to show which of the approaches in REST / CRUD in my opinion are erroneous and detrimental to the project.

Must have for all resources

To continue the narration, you should immediately determine the minimum set of object properties, addressing, and other delights. Let's start:

• The URL is such a thing, by clicking on which you can get 100% information about the current state of an instance of an object. Has the form

    <protocol: //> <server: port> / <path> / <resource> / <slug> 

• URN - this is such a thing, by clicking on which you can get 100% information about the object. It differs from the URL in that it does not bind to a specific protocol and server. In 99 cases out of 100 it makes sense to use one thing. Has the form

    <path> / <resource> / <slug> 

• A URI is such a thing, comparing that between objects you can 100% say if you are working with an instance of the same object. In other words, if for 2 or more objects their URIs are correct, then this is the same object! Has the form

    <resource> / <slug> 

• resource is such a thing, comparing that between objects you can 100% say if you work with instances of the same collection of objects . In other words, if for 2 or more objects their resource is correct, then these are objects from the same collection!
• A slug is such a thing, comparing that between objects without being tied to a resource, you can 100% say that you are doing something wrong. In other words, if for 2 or more objects their slug is correct, then this DOES NOT MEAN ANYTHING ! Serves solely to uniquely identify an instance in the collection !

The important difference between slug and id

• id - integer value that means NOTHING to the user
• slug is a meaningful string value. Usually with underscores (or periods) instead of spaces

For sql-tankers (no offense) I will explain:

• id in the table - for data integrity in relationships. Has restrictions NONULL, UNIQ, INT
• slug - for the API. It has restrictions NONULL, UNIQ, CONST and NOT USED in relationships.

For example, users.id is an id, but users.login is quite a slug.

And now we take for an axiom “all objects must have the specified properties,” and, so as not to blur over the object, we stuff them, for example, in the property "__link__":

{ __link__: { url: 'http://localhost/api/users/vasya', urn: '/api/users/vasya', resource: 'users', slug: 'vasya' } } 

By the way, this is a valid object. He could return from some url (not “ localhost / api / users ”). The developer, having received such an object, should request the data by url / urn from __link__, but more on that later.
By the way, "according to the correct" - do not add. property "__lnk__", and use for these purposes the headers of the format X-URI, X-URN, X-URL, etc, but not all weber like to work with headers. Mol took the body and ran.
Hmmm ... and how many implementations of the REST API have similar properties? Maybe I invented the bike?

CRUD / Read or HTTP / GET

It's simple. We take the URL, we request the object, and ... And what about "and"? And sometimes we see the following answer:
Example:

  HTTP / GET http: // localhost / api / users 

 { status: true, count: 100, data: [ { login: 'vasya', name: 'Vasilii', id: 146, __link__: { url: 'http://localhost/api/users/vasya', urn: '/api/users/vasya', resource: 'users', slug: 'vasya' } }, { login: 'petya', name: 'Petr', id: 145, __link__: { url: 'http://localhost/api/users/petya', urn: '/api/users/petya', resource: 'users', slug: 'petya' } } ] } 

What's wrong here:

• Why is there a "status"? HTTP / 200 not enough? Or your server can not send the text of the error message? Sending HTTP / 200 with “status == false” - hiding the error. If the backend does not have logging at the point of error, we will debug for a long time in search of what is happening. While the server's http log immediately tells you which url an error occurred.
• This kind of “wrapping” causes webers to write “unwrap functions” to display an error message or get data. Although for a full debug it will be enough to have a problematic URL.
• Hmm ... And if the elements are +100500, and one of the admins changed the "name" property for the user "petya"? Or, more often, a new user was added to the collection and the count is already 101? That's right, you can forget about HTTP / Cache-control - we will pull the entire list on a new one.

Conclusion: I do not know if this is correct, but so far all the arguments are not in favor of this approach.
')
The answer should be:

 [ { __link__: { url: 'http://localhost/api/users/vasya', urn: '/api/users/vasya', resource: 'users', slug: 'vasya' } }, { __link__: { url: 'http://localhost/api/users/petya', urn: '/api/users/petya', resource: 'users', slug: 'petya' } } ] 

At the same time count should live in HTTP / HEAD, since does not have a direct relationship to the resource, and describes the state of the collection. Again, you need to display the number of users. How to be? Choose everything and count in javascript? Write a new url to get count of items? What for? Make an HTTP / HEAD request for a collection. There will be no data, only the headings will return.

Skeptics will say: to draw all the elements, you will have to make a lot of requests to the backend,
My answer: HTTP / 1.1 / Keep-alive will save us all. When using javascript frameworks and caching - most of the data will be requested during initialization, one-time, and after - they will only exchange requests with the HTTP / 304 response (the resource has not changed).

Do you know why weber do not like this approach? They have to control the receipt of data from the server for normal display.
For example: If the data arrives immediately with the properties, you can immediately draw several divs in the loop without worrying about synchronization. If you make 4 requests to display 4 lines with users, you must somehow monitor the status of all requests. Those. until ALL requests have worked - do not draw anything. See Promise and Future to solve these problems. They all have code for forced synchronization, although I would draw right away as it is ...

PS At 2:30 o'clock. I really wanted to tell you about the nesting of resources, about the massive DELET / POST / PUT ... but I guess I'll go to sleep. I will leave this opus to the public. I ask you to comment in the comments - is it worth it to continue or the truisms are not in fashion?
PPS I would be very grateful to people for the different rakes that had to occur when working with REST API from third-party developers.
Thanks to all!