Tag Info

New answers tagged

0

As it turns out, I was viewing it from the wrong perspective. I can build my webservice with any programming language I like, deploy it on some test server and test it with Fitnesse and RestFixture. No problems.


4

When creating a REST interface, there is no requirement, or even expectation, that the responses on the REST interface correspond directly to tables or joins in the database. Your /streams interface can just as easily be represented as [ { "listen_count" : 5, "user" : { "href" : "/users/10", "name" : "bla", }, "song" : ...


2

You definitely want a single GET operation that returns metadata about each song and user in addition to their opaque ids. As you pointed out, it's much simpler. That is a good thing. Making one of the most common operations for your client apps a single server request instead of O(n) requests is much more scalable. In the long run, the network will be ...


3

REST services are typically focused on resources, with the path separator (forward slash) denoting sub-resources in a hierarchy. Resources are typically things ("nouns" in English) rather than actions ("verbs" in English). To conform to this style, your "suggest" endpoint (a verb) could be named "suggestions" (a noun) because it provides access to ...


2

There is couple of comments that I would suggest you. You name your resource using verb instead of nouns. suggest is not really a good resource name. It give the client the idea that you are building a controller action and REST does not like it. suggestions is a better name. Now you can view it as a resource set of suggestions which is more RESTful. ...


2

In the first place it seems to be right, but I think you want to hide these implementation details. Ask your self: where is the difference between a local database and some remote data servers? You probably want to have a been for each resource like User and a store like UserStore. Each store has some methods for interaction like: public User ...


1

First of all, don't put REST above solving problems efficiently. In order for clients to be able to log in you need to somehow store some state. Whether or not you consider this to be against the REST mantra doesn't really matter, you need to do it anyway. You could make digitally signed tokens containing all session information, and not store those on the ...


5

The statelessness of REST refers to the side of the server. If you pass around your token in every request this becomes part of the state that is being sent from the client and therefore does not violate the statelessness of your server. This differs from, for example, managing state on the server where you keep information in the session server-side. A ...


4

The technique your boss has told you to use is one of the common ways of preventing cross site request forgery. I think you're probably getting confused by the multiple meanings of "hash" which in this case probably refers to a secure hash (eg SHA256) rather than a hash that you might use for a hash table.


11

The API being designed follows the Rest style of resources-centric URI and CRUD operations mapped to HTTP verbs. This is your problem right here. You have limited your resources to (I'm assuming) the models in your database. As such it is taking ages to load all these resources because your server has no concept of resources that don't have a ...


1

I suggest that you 1) learn what other REST APIs do, and 2) consider OData I love Odata because it supports every scenario you listed in one single API call. I'm biased though, because in C# you can implement an Odata server in just a few lines of code if you use the Entity Framework. There's also client side libraries that can format OData URLs. Let me ...


3

This is a classic API design dilemma, regardless of whether it's provided by a web service, or by linking a library, or by just being part of a code base that gets built along with everything else. It boils down to whether you prefer many functions that each do one specific thing, or whether you have fewer, more parameterized functions. Since web calls are ...


1

I have done such things as REST, which, as you say, doesn't solve all problems, though at least a few of them possibly. Basically search features I have implemented using URL params instead having a single URL for each of them. So your get_user_by_email would just be /user?email=joe.doe@something.net Similar you can handle the returned data for things ...


0

My understanding of CQRS here, is it definitely feels like a disciplined implementation strategy for the middle tier more specifically (*) itself a supplier of the service tier (which calls into CQRS) - e.g., WCF, and a consumer of the domain model/data tiers (which is called from CQRS) - e.g., ADO.NET, Entity Framework, or whatnot. So, unless I missed ...


-2

Just use external IP to to interact with server machine, means u can pass. 1) start the Remote server (tomcat) 2) check the network , if Client and server in same network use internal ip otherwise use external ip.


1

Regarding the table, if a book can have many labels and a label many books (sounds quite reasonable) then that's a many to many relationship. In case of REST the many to many relation is in fact a bit confusing since we talk about resources and with the URI being a unique identifier it seems weird to be able to access one and the same resource from two ...


0

Since permission should be on a resource level you generally check permissions on a resource before you start validating data, since what is the point of starting validation of the data if the user lacks the permission to change it. This is how most web frameworks work, permission checking happens right after routing. Once the user is granted access to ...


1

Consider using a queue, where each method access resulting an entry, and use a timer job queue length reaching certain threshold to flush the queue into the database.


2

You can set a threshold. For instance, you can store that someone visited at 14:00PM, and then audit if the difference between then and the current time is more than 30 minutes, so you have 2 updates per hour at most. If you have a stateful service, another approach would be to store the time of each request in memory (default session driver, Redis, ...



Top 50 recent answers are included