New answers tagged

0

With the second approach there is potentially a performance benefit, because you can update directly the DB without checking if the post is already liked / disliked. (Only an update, versus a SELECT and then an UPDATE) Probably you already know if the post is to be liked or to be disliked, because this action come from a GUI which show only the relevant ...


1

Semantically it is a create or update scenario, which is what PUT (which is also idempotent) means. so make a HTTP PUT request to a single endpoint with the value for like. {like: true} for liking and {like: false} for disliking.


0

In general, the overhead involved with AJAX requests is higher. If an Ajax request has, say, 1K of transport overhead, then sending 50 bytes over a single request means that your transfer of actual data is only about 5% efficient. Ajax requests are typically made to RESTful resources. Socket communication is a persistent connection, and seems more suited ...


1

With your first scheme, your endpoint is not idempotent (i.e. if you execute it twice it doesn't do the same thing as executing it once). With the latter scheme, you can easily implement it to be idempotent (and potentially use a PUT method). In this case, if the "user" likes something they've liked before, it should just succeed and do nothing. This ...


0

You can use Partials Partials begin with a greater than sign, like {{> box}}. For example, this template and partial: base.mustache: <h2>Names</h2> {{#names}} {{> user}} {{/names}} user.mustache: <strong>{{name}}</strong> Can be thought of as a single, expanded template: <h2>Names</h2> {{#names}} ...



Top 50 recent answers are included