Alice wants to pay Bob for a service. Bob has quoted her $10.
Give this quote a unique token.
Alice clicks pay.
When this response is send to the server, it must go with the token of what is being paid. This also allows you to discard duplicate payments.
Whilst Alice's request is flying through the ether, Bob edits his quote. He now wants ...
A quote should be a write-once record.
Bob isn't allowed to edit it once it has been created and passed to Alice.
You can ensure this at different levels, from simply not offering an edit dialog to sophisticated digital signature algorithms.
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 ...
This must be an extremely common problem to deal with, no?
No, it isn't. I doubt you'll be able to find a payment processor that lets you change the amount after the customer has authorised a particular amount.
You sell to Alice at the price she authorised, because that's what your quote to her was, and what she authorised. You don't check that the money ...
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 ...
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 up ...
Just send the amount Alice agreed to pay along with the request. If the price has increased since Alice sent the request, you send a response indicating that the item could not be purchased at or below that price, and the current price is whatever it is. This is pretty much the same situation as when there's only one item available and, at the time the ...
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 ...
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 ...
Building a web application is absolutely more complicated and harder to build than client-server, for a given set of features. There are a variety of reasons and ideas I'll describe in no particular order.
The highest voted question of all time on this site is What technical details should a programmer of a web application consider before making the site ...
the solid, defining line on can/can't be server-side by taking requests and returning a database call, that is puzzling.
Quite puzzling, I'd imagine, given that such a line does not exist for languages.
As pointed out in the comments, "server-side" is not an aspect of a language. It's not even an aspect of a language implementation (meaning whether it's ...
I think your confusion is between the technical term "client" (as in client-server) and the business term "client" (as in, a paying customer). Multi-tenancy usually implies a server serving multiple business clients, each with their own separated environment, using shared hardware and software.
For instance, I have several Wordpress blogs running on a ...
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 ...
First, you will need **HTTPS**.
HTTPS = HTTP + SSL/TLS.
It creates a security layer on top of your HTTP and prevent a lot of attacks. For that layer to work you will need to trasmit and receive credentials in a form of an certificate. see HTTPS
HTTPS can be configured in One-Way or Two-Way.
One-Way: In the One-Way scenario only you send your server ...
You can use a technique often referred to long-polling or comet, which allows to implement a "push"-based event/update system.
The principle is rather simple:
client 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 on ...
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 server....
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 ...
No, not necessarily. What you need to understand is that the Web architecture is a Client-Server architecture, it's just that the Client here is provided for you (the browser).
The real question is, does the browser meet your requirements? Can it perform all the operations you want of the Client? If so, it may well be easier to re-use that existing Client. ...
Your third idea seems to be the closest to what I think of as the industry solution to this sort of problem.
What you're describing is commonly referred to as Ticks. In each tick, a fixed number of actions would be processed for each client in serial. Often times, game servers will have some parallel actions when capable, but this is a much more complicated ...
I'm looking for a formal way for a front-end and a back-end team to
communicate on the shape of a JSON web API
@RobertHarvey hit the nail on the head.
Unless this is a public API, the usual way to communicate a contract
is to document it. That works no matter how large the team is; in
fact, the larger the team, the better it works
I suggested ...
Yes this is a common issue, and it is about transactional consistency.
To summarize your issues:
the quote is binding for the seller. In general it has a reference and an expiration date/time.
the buyer may buy under the condition of an accepted quote. The buyer cannot be forced to accept a price that was not agreed.
if a buyer finishes the transaction ...
Yes, you should validate what you get, but you also need to be a Tolerant Reader:
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 ...
MVC relates to the design and structure of an application as it pertains to the internal flow of data, and the eventual presentation of that data.
It is entirely orthogonal to whether that application is a server, or is a client, or is both a client and a server.
I have been reading up on UDP connections
There is no such thing as a "UDP connection". UDP is a connectionless protocol, that is pretty much its reason for existing in the first place.
So if something happens and only two packets out of the three get sent:
How do you even know that? There are no sequence numbers in UDP, every datagram stands on its own....
In my limited experience, the points where validation are required are
The presentation level using HTML,
at the combination level where interactions between multiple fields have to be validated
at the business logic level and
at the database level.
Each of them have different ...
I would Check Availability on Failed Action. Just issue your calls normally and if you get a failure, then call the Service Availability function to verify.
Assume service is up, if one gets and error, then issue the additional call to verify availability.
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 ...
If you google "REST partial update" you will get a lot of opinions.
Having said that I'll give you my thoughts.
A PUT should be used for a full update of a resource so only changing one parameter you are better off PUTting to /purchase_order/1 a recent result of a GET to /purchase_order/1 with the status field changed from draft to sent.
Depending on ...
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 ...