Tag Info

New answers tagged

1

Like many important ideas, the concept is more important than the implementation detail. You could write a web-service that simply used HTML. This wouldn't be a great idea — using a JSON parser on { customerList: [{ id: 4, name: "John Doe", ... }, ... ] } will get you off the ground a lot faster than using an HTML parser on ...


0

Buzzwords come from good marketers and clever analysts. Large software vendor X has a tool it has spent X on building. An analyst (eg Gartner boy xyz) can make a big name if he coins a terms the sits. Or is first to write up and analyse an emerging trend. Sheer ignorance. If A topic that is poorly understood but used by many also tends to have a hype ...


1

XML and JSON are more flexible than HTML, because they're designed specifically to handle data in an agnostic way. Yes, you can parse HTML and do something with it, but it's not really designed for that; it's designed for displaying UI. XML and JSON, on the other hand, can be consumed by a frontend like Angular, and used to display data in an HTML page. ...


1

It mostly depends on the size of the data you return and whether the user is expected to use all the data at once. For instance, if it's a list containing hundreds of thousands of complex entries: The response served as a single JSON will be rather large, and: It is unlikely that the user will actually need to see all the data at once. Instead, the user ...


1

Generally you don't keep them in sync in that way unless there is a reason to do so. Your entire premise is flawed. Most of the domain logic in an SPA, like any application, should be in the server. Only logic pertaining to the user interface should be in the client. Edit: So just to be clear on terminology. I assume that when you say "domain logic" you ...


0

JDT There are specific implementation answers to this problem developed by various software stacks, see JDTs answer. Router I think a fairly simple solution is to get your router to do this for you. You can define a mapping between incoming requests at a known and static port on the router and the server (including the port number) the requests should be ...


0

You can avoid this issue by using a host name without a port and leaving the mapping of that host name to the target port to the server. This way, when the port changes (which is something you do on the server) you can change the mapping as well (which would also be on the server). Depending on the web server you are using, you could use Host Headers (IIS) ...


1

Use 200 Ok The setup you propose is common with a service orientated architecture (SOA). When using asynchronous messaging you typically have a flow like: --> Request <-- Delivery acknowledgement <-- Process acknowledgement --> Delivery acknowledgement It is typical to use 200 Ok for a successful delivery acknowledgement. I would expect this ...


6

The successful creation of the task to do whatever was successful. This means that one should be looking in the 2xx block of the response codes. In this block one jumps out as the correct answer quite quickly: 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not ...


1

You miss the opportunity to report errors that may occur while processing the message. That way the consumer of your service can never be sure if the call was successful.


3

404 is perfectly fine for this use case. 4xx status codes are client error codes, so browser treats them as such, and that is perfectly fine too. Another kind of APIs (e.g. JSON-RPC) use different approaches, but since you're going RESTful, do not change response code just to make console output look pretty - it is not a use case, users are not supposed to ...



Top 50 recent answers are included