Hot answers tagged

73

A client is identified by a cookie as well as the IP address. However, the IP address cannot be used exclusively: What if two clients are located behind the same NAT firewall or proxy? They will have the same external IP address to the server. What if a user has two different browsers open on the same machine, and wants two separate sessions (maybe for ...


17

This question is a bit opinion based, but either way. The way i see it, 200 can serve "soft errors". When it comes to building API's i try to distinguish between these and "hard errors". "Soft errors" will be served with a status code of 200, but will contain an error description and a success status of false. "Soft errors" will only occur when the result ...


15

Sometimes you can use IP address. If you're on a LAN or are otherwise dealing exclusively with users that have IP's statically distributed to single clients, using that address is perfectly fine -- sometimes preferable and necessary. But, usually you can't. If you're running a public site, most of the IP addresses that hit your server aren't static or ...


13

Interesting question. Basically, we can reduce this down to the right way to classify things in terms analogous to OSI layers. HTTP is commonly defined as an Application Level protocol, and HTTP is indeed a generic Client/Server protocol. However, in practice, the server is almost always a relaying device, and the client is a web browser, responsible for ...


12

The latter has the advantage that it makes your "back end" a generic "data service" (whatever that may mean in your context). Your HTML client is then just one of the many possible consumers of that data. Think iOS app, Andriod app, Windows 8 app, APIs, etc. -- as other consumers.


12

There are two aspects of an API: The effort to implement the API, and the effort of all the clients to use the API correctly. As the author of the client, I know that when I send a request to a web server, I may either get an error (never talked properly to the server), or a reply with a status code. I have to handle the errors. I have to handle a good ...


8

client/server refers to a relationship between two networked computers in which one machine (the client) initiates a connection and makes requests of the other machine (the server), which in turn to fulfill those requests. Servers exist to provide a service which clients consume. Also, have you checked the Wikipedia article on REST? The second paragraph ...


8

The client and server are basically two parts of a distributed computing model. In this model, a user uses a client computer which sends requests to the server. The server then processes the request and creates the appropriate response which it sends back to the client. In this model, it is often the client that initiates the interaction and not the ...


7

Three more reasons to add: Multiuser workstations and terminal servers exist. Many users could be running completely independent browser processes in separate sessions. IP addresses aren't persistent. It could be reassigned when a DHCP lease expires. The application should support roaming. For example, a user on a phone might drop out of WiFi range and ...


7

Yes, you should validate what you get, but you also need to be a Tolerant Reader: http://martinfowler.com/bliki/TolerantReader.html Martin Fowler states that: My recommendation is to be as tolerant as possible when reading data from a service. If you're consuming an XML file, then only take the elements you need, ignore anything you don't. Furthermore ...


6

Why Rewrite What you can Get Off the Shelf? Why not use RedDwarf Server (formerly Project DarkStar)? RedDwarf Server is an open source middleware solution for developing the server-side of massively multiplayer online games. It is the official community fork of Project Darkstar, an open source project supported and managed by Sun Microsystems. - from ...


6

You can use a technique often referred to long-polling or comet, which allows to implement a "push"-based event/update system. Principle The principle is rather simple: clients sends a request to server and keeps connections alive; server keeps a handle on the connection and waits; when updates are available, server sends back data to client; (depending ...


6

In my limited experience, the points where validation are required are The presentation level using HTML, at the post-presentation level (i.e., Javascript validation), at the combination level where interactions between multiple fields have to be validated together, at the business logic level and at the database level. Each of them have different ...


5

A growing common way of a web application is a mix of both, tending one or other side. The first approach is more traditional, has been there for years and its well documented, (although c++ is not generally a language popular for that). The second option is more modern, and are in the development blogs and forums nowadays. One of the reasons for that, is ...


5

This is an ordinary sandbox model (the one which is used with plugins/addins). Instead of calling the libraries directly, you load them in a different AppDomain. Doing this actually allows you to update the corresponding libraries while the application is still running. If you want to automate the process, the client application can monitor the directory ...


5

If the server only responds to requests from the client and new interface versions only add new requests (existing requests and responses are never changed), then disallowing newer clients means that neither client nor server need to explicitly support multiple versions of the protocol. In that case, if a version 8 client connects to a version 10 server, ...


5

Guessing the encoding of a message based on its byte values is always imperfect, although it can be made to give relatively accurate results. There are libraries available to do this, e.g. IBM's ICU. But the preferable option is always either to standardize client and server on one encoding and always use that, or to force the client to declare the ...


5

the app we are building won't simply look at the links and then by itself render the correct UI and make the right ajax calls In fact, this is exactly what HATEOAS will give the UI. Not what is possible, but when it is possible. A formal HATEOAS like HAL, as the question states, gives links that indicate what is possible. But when those links show ...


4

I've done two relevant (for this question) projects. The first uses SOAP, a Java server and a .NET-Client. The second uses REST, but both, client and server, are written in Java. Your pros and cons seem all valid to me. I personally like REST-style messages more. The main-reason for this is, that it's very lightweight (in action and development), what you ...


4

For such "intranet" applications I use the fat-client (JavaScript/HTML5-app + JSON) approach with ExtJS4. For normal "internet" websites I would use a more "classical" approach. The clients have to render the site anyway, so why not charging them with the whole process and just give them the data to fill in. It simplyfies the server code for generating ...


4

There are no silver bullets in design or architecture. ( Sorry ) It sounds like you're still at the beginnings of the Design phase and I think you need to focus more on the "divide and conquer" aspects of mapping out your application. Rushing into the lower level details before you have a comprehensive design means you may miss otherwise "obvious" ...


4

Most client-server applications can be installed in a "standalone setup", where the client and server machine are the same, as you wrote, but that does not make them a "standalone application". Such a system is still a client/server application, and the interprocess communication between the client application process and the database process will typically ...


4

Every software development technique we've ever invented has been about managing complexity somehow. A huge portion of them have been and continue to be about abstraction, encapsulation and loose coupling. Microservices are yet another way of doing those things, which is probably why it resembles a lot of older techniques at a high theoretical level, but ...


4

It's generally easiest to update the server first and then update the UI when the server responds with success. This allows you to avoid handling cases where you updated the UI but the server update fails. But it also makes your users wait for the server request to complete before seeing the results in UI. Which way is best depends on your priorities, and ...


4

I recommend keeping your RESTful interface stateless. This means for every request, you must pass in all authentication information. I have used Basic Authentication (credential in HTTP headers) with great success. Keeping your RESTful interface stateless greatly simplifies your server logic and your client's logic. Every request is autonomous, and you ...


4

Yes it is transferred by HTTP. Your example url kind of obscures the fact because you have left out the scheme (the initial "http:"), but if you enter an url without a scheme in a web browser, it will default to http, hence the url is actually: http://www.example.com/download?=test.doc A HTTP response contains a header and a payload, and the payload can ...


4

Why on Earth wouldn't you? A good rule of thumb is to assume that all input is evil until proven otherwise. Blindly assuming that your input will be valid is a good way to wake up to empty databases and overflowing error logs. Just because that input is coming from a (presumably proficient) coworker's server doesn't mean it should get a free pass from you. ...


3

How much domain logic you have in the client-side UI will depend largely on how much interactivity and responsiveness you want in the UI. For example, let's say you want to validate some field that the user enters. Maybe that validation involves other fields on the form (you asked for socks, but you didn't specify what color of socks you wanted). In most ...


3

One consideration that often limits solutions is the network round trip. The client is supposed to validate the user data without sending a message over the network. In other words, when the user hits the submit button, the client is supposed to validate the data locally. First, let's assume that we do not have this limitation. We could communicate with ...


3

There's one thing you mention in the last paragraph that stands out to me: the client is already feels bloated and complicated. The modern approach to client/server relationship is a parallel of the relationship between human and machine. Client Akin to iOS programming, we ought to perceive the Angular front-end as a View-Controller. Don't use models ...



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