It effectively does so, by making some (not completely founded) references to WS* features. But if people who really understand REST can't agree on something then what hope is there for those who just want to go and use it? That's what REST-* is about: bringing together communities to try to come up with clear guidelines so that there's a place for everyone to go when they need those answers.Īlthough this new initiative is trying to stay away from REST vs WS debate: The benefits of REST over WS-* has been debated across many articles, blogs, and public mail lists. Does that mean the answers don't exist? No.
In some cases they'd get many different answers. They kept running up against the same questions and lack of clear answers from various sources such as books, experts in this space and other resources. this was started: because our community wanted it. (By the way, the above quote from Mark Little already contradicts with the architectural goals mentioned before, by hinting to both new protocols and non HTTP support).Īccording to Mark: If the only thing we end up being is an aggregator for links to "standard" ways of accomplishing this or that then that's a successful outcome too. That might include security, management, etc. but one of the main points about this whole effort is to document guidelines and best practices for doing things in a RESTful manner (both with and without HTTP).
They are envisioning an open source approach to. Isolate data formats to extensions If possible, specifications should try not to define new data formats.Īccording to the announcement, JBoss is attempting to create a fully collaborative community, similar to, not something driven by vendors for vendors. In most cases HTTP headers should be enough to transfer metadata about the request, response, or resource. Envelope formats encourage tunneling over HTTP instead of leveraging HTTP. Edge cases should not be in the main specifications.Īvoid Envelope formats Whenever possible, avoid envelope formats. Specifications should cover 80% of the most common use cases. If you need to bend the rules of REST to create a simpler design, then that's the path that should be taken.Ĩ0/20 Rule Specifications should remain simple. Pragmatic REST While a specification should strive to follow RESTful principles, simplicity should never take a back seat to being a pure RESTafarian. Extensions should strive to be layered on top of the main specification.
SAP SOURCING WORDSERVICE NOT RUNNING INSTALL
They shouldn't need to install a library or large stack of software to use a specification.Įdge Cases should be Extensions Edge cases that complicate the main specification should be defined in a separate sub-specification. Low barrier to entry Clients that use the specification should have a very low barrier to entry. The architectural goals of this initiative are: It is simple, robust, and flexible enough. WS-* requires an envelope format The WS-* stack requires SOAP, an envelope format for WS-* sent message. We hope to minimize the barrier to entry in our suite of specifications.
WS-* has a high barrier to entry The WS-* stack is hard to implement and requires a complex stack on both the client and server to use. Because we are focusing on RESTful principles the specifications put out by this organization will fully leverage the HTTP protocol and not try to re-invent its technology WS-* services mainly use HTTP as a connection setup mechanism and ignore the rich and proven features that make the Web so successful.
WS-* doesn't leverage HTTP WS-* uses HTTP as a transport protocol. While a vast improvement over CORBA it does suffer from a few disadvantages that the REST-* community hopes to fix, mainly: WS-* is an excellent set of specifications defining various protocols and envelope formats for implementing middleware services over a network. REST-* is trying to clearly separate itself from WS-* by pointing the following differentiators: JBoss has formally announced a new REST-* initiative during JBoss World at the beginning of the month.
0 kommentar(er)
