Tag Info

Hot answers tagged

3

The best practice is to store a datetime stamp in the user's table that indicates the last pull by the browser for notifications. Any notifications created after this datetime stamp would be counted as new and unread. The database can index notifications by their created datetime stamp efficiently, and adding a flag if read shouldn't impact performance. ...


1

Before I answer your question, a couple of points about your example: REST is based on resources, so the ID for e.g. a User resource would usually be part of the resource path (rather than a URL query parameter): GET /user/1 Inserting is adding an entity to a resource collection, so to insert into e.g. a User collection you'd usually use something like: ...


1

Your second approach—including in the job model only links to actions the user is actually entitled to perform—is the one I would take. It keeps the focus on the resource and the actions that can be performed on it, which makes it both relatively simple and a good fit conceptually for the REST architectural style. It retains on the server all ...


1

There is no definitive answer: some people will be inclined to add comments to every class and method; others will try to avoid commenting things which are already explicit enough. If you follow StyleCop default rules, you have to comment every member, including private fields. You might want to suppress the warnings if the code is really repetitive. But ...


1

I'd structure it by moving it inside the json fields if HTTP basic auth isn't an option. For example: POST https://my.server/login { "username": "user", "secret": "someSecureHashAndNotThePlaintextPasswordSeriouslyDontDoThat" }


1

I would prefer to design these as subresources, onto which you perform a POST request. Consider you have a resource at /instance/type/1, I would have the representation of that resource convey a couple of links to 'actions' that can be performed on the resource, such as /instance/type/1/draft and /instance/type/1/curate. In JSON, this could be as simple as: ...


1

REST is an Architectural Style of building Web Services. It's just a model that says that you could use HTTP and its verbs (POST/PUT/GET etc.) to perform CRUD on Resources exposed by your Services. But REST lacks any details on how the URLs should look like, how to request/response formats should look like, how to query information or at a basic level what ...



Only top voted, non community-wiki answers of a minimum length are eligible