Tag Info

Hot answers tagged

2

The biggest problem is the huge set of assumptions that you so easily skip. Just take your example: "$600 is paid by Client A for inspection" USD or other dollar? Paid when? To whom? What counts as an inspection? Is this a mandatory payment, or only incurred if A opts to do the inspection? Are multiple inspections allowed, If so, is this per inspection? ...


2

At the syntax level, either XML or JSON would do fine. But that's the easy bit. The challenge is defining what can go in the rules. I would adopt a standard object modelling approach: what are the entities you need to represent, and what are their attributes and relationships? When you know that, encoding it in XML is easy.


2

The most commonly accepted way is to use a Business Rules Engine of some sort. Of course, if you're willing to roll your own BRE, and just need a reading on the markup language to use, I would imagine that XML is as good as any. It is hierarchical, has namespaces, and is unlikely to become obsolete any time soon. Since it's likely that we're not talking ...


2

Plain JSON isn't RESTful since it lacks the hypermedia constraint. If you are making a small-scale web application and don't need the development overhead of REST, however, then plain JSON will work just fine. The Internet hasn't settled on a favored JSON hypermedia format. There are multiple formats available, each with their own pros and cons, and you ...


1

While you do not anticipate changing the nature of your objects now very much - needs change over time. I would highly suggest you consider using protobuf or Apache Thrift or a similar design instead of relying on default Java serialization. Their advantages include strong support for avoiding impact during minor version changes, significantly better ...


1

You really should do only one of two things Either Return a 200 (OK) status code, and an empty array in the body. Or Return a 204 (NO CONTENT) status code and NO response body. To me, option 2 seems more technically correct and keeping in line with REST and HTTP principles. However, option 1 seems more efficient for the client - because the client does ...



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