Creating "fake" identifiers in the REST API

I have a list of Post objects, and each post has a list of Comment objects. The Post object is a composition object. There are no comments in the system.

Example URI:

/posts/3453/comments/8547

This returns a specific comment and is also used to delete and update a specific comment. Now it would be better if my API had something like this:

/posts/3453/comments/1

If the comment identifier 8547 in the first URI matches the last, but the identifier is in the context of the message. It starts with one and increases when more comments are added. However, if you had 10 comments with an identifier of 1-10, and then deleted the number 5, should it update the identifiers in some way in order to apply 1-9?

Does that even sound reasonable? Am I just starting to think about it, or should I just use unique identifiers (primary keys) from the database? If not, how would you create such identifiers?

+4
source share
3 answers

If you decide to identify the comment by its serial number, this is your preference. If in the concept of your application it makes sense to make a unique identification of the comment sequence number when it is associated with the mail identifier, this is an absolutely beautiful design if it is documented.

There are at least two major obstacles to your re-sequencing approach, which can lead to the incorrect development of your application URI. The first fall, the GET methods in the URI must be cacheable, re-ordering violates this contract because element 2 has not changed, but since element 1 you have now changed, which means / 2. Further, this will obviously lead to breaking links that people could create.

I like the concept of a query parameter for a sequence, however, I believe that from my limited understanding of your problem, it makes sense to just use identifiers simply because the two overflows that I list above are no longer problems.

+3
source

The numbers 8547 and 1 look the same, but they represent different concepts: 8547 is the identifier, and 1 is the serial number. This is normal if the sequence numbers are changed, but it is not normal for identifiers.

I would recommend using a URI with an identifier to identify a specific comment resource and add a UIR with the ability to query to search for a comment resource by its serial number, for example:

 /posts/3453/comments?sequence=1 

Thus, there would be no questions about the β€œcanonical” URI, but clients could request comments without the need for complete identification.

+3
source

Instead of using an index scheme, I would definitely go with the actual comment id. The reason is what happens if there are several updates in a row? User A deletes the comment in index 2, while user B deletes the comment in index 3. Well, which comments should really be deleted? The actual deletion will be determined by the order of execution. If you use real identifiers, you do not have such a statement.

+2
source

All Articles