I am doing some research on web services. I have not written any web service but I am doing a small write up on them.
During my research I've come across terms contract-first and contract-last.
Can someone explain these two in an understandable form ?
To expound on the answer by Kaleb, contract-first is where you create the WSDL, and then you can create the implementation from this, and since the WSDL is your contract, this would be contract-first.
Contract-last is where the WSDL is created from the source code, or implementation, so it will most likely be generated by a tool rather than created by the developer.
Update:
For a nice explanation with code, in Java, you can look at this explanation from the Spring Web Services 1.5 documentation.
They will discuss the pros and cons, though they will be biased toward their approach (which is contract-first). Anyway, I think it is a nice explanation.
Contract-first means you design the way your services are going to communicate with each other before you design the services themselves.
Contract-last is the other way around – you design how your service is going to work, then make one or more methods available as the interface for other services.
Related
We have a number of existing asmx web services that are used by many, if not all of our clients. These are not going to be re-written en-masse any time soon.
My simple question is therefore whether it makes sense to create a new web.api layer that underneath call the existing web services where required (until they are rewritten) and new methods could do without the "legacy" soap services. What this would ultimately mean is that until the time the existing web services are re-written / ported to web.api then we'll effectively have two interfaces.
I know that things are generally heading in the REST direction, and so for future projects, interacting with web.api nay be a good way to go. Scott Hanselman has previously said that "if In doubt add another layer of abstraction", but I'm not convinced he was serious :)
The problem here is that the methods of your SOAP-based API are unlikely to map onto the more resource-orienmtated design of a REST API.
Also, from a performance point of view you'll wind up with something pretty clunky if you place a web service facade over a web service.
REST is increasingly popular, but it's not true to suppose that everything is moving in that direction. IMHO there are times when the structured exchange defined by a SOAP contract can make for a very useful API.
I certainly wouldn't bother wrapping an existing SOAP interface to create faux REST.
For personal and university research reasons I am thinking of building a simple CRM using a service oriented architecture. Its meaning is just to explain the architecture itself, not commercial use.
I was thinking of implementing a CRM that offers a simple analytics service and customer care (user storing, personal comments, and few other things).
The architecture that I'm designing defines:
- WebGUI (a client of the other services)
- AnalyticsService (a service that receives data, analyzes and collect it)
- CustomerCareService (a service that uses RESTful APIs to apply CRUD operations).
Each service has it own database, being completely independent from others. They expose a public interface. The interface of course must provide some sort of authentication, to deny unautorized requests.
The advantages I'd like to explain in this kind of architecture is the possibility to have all things indepentent and the ability to combine them to offer new services (for example if there was an OrderService to handle orders it would be easy to combine it with Customer using the public APIs). The big advantage to me is that it'd be easy enough to build other clients that use these services.
I don't know what is some good Authentication method, that could be easy to implement, I'm also not sure about how to make this APIs (use XML or plain REST APIs with GET/POST data). I've worked with Amazon, PayPal and other company APIs, they seem to use REST services (paypal uses an ugly _cmd GET parameter while Amazon uses better URI) to know what to do, but reading something about SOAs it appears that people also use XML. Of course I also need to take into account that the web interface must be able to recognize the logged in user, get the permissions (token or whatever else) and use it with services to show information.
So I'm not sure SOA is the kind of architecture I'm really building up... is it SaaS instead of SOA?
I think it would be better to use RESTful applications, with JSON or something like that to implement it (I'm not a big fan of XML, I find it to be too verbose).
For clarity I'm listing here my questions:
Is this kind of architecture called SOA or SaaS (or both)?
What is a good implementation for what I want to obtain? (please explain it as more detailed as possible)
What sort of authentication is more suitable for a client (user token vs OAuth or similiar)
Do you have some suggestion for this kind of project?
I've about 3 months to do it, so I cannot do something real complex (beside the fact that it would not be realistic for a single programmer).
I know Python (WSGI frameworks), Ruby on Rails, C/C++ and other languages (.net excluded) and I'd like to develop it under a Linux environment (MySQL or Postgres, or even a NoSQL if you have any suggestion for the right choice), I could also combine several languages being these services independent programs.
What I'd like here is to have some good point of view and some good suggestion.
Thanks!
I would define SaaS as a Business model rather than an architecture; however like all business domain requirements it will influence systems architecture but it, itself is not. What you have defined is essential a Service Oriented Architecture.
Your statement "independent and the ability to combine them to offer new services" is the essential non-functional design requirement that suggests SOA.
Good implementation for SOA is about having well defined and flexible interfaces, with very clear delineation of responsibilities. However it is difficult subject to be prescriptive about. The proof is in the eating; does it provide that flexible reuse. My suggestion is spend time reading SOA design pattern resources, and understand the defining characteristics with regard to the appropriate context for use. Then apply the Single Responsibility principle appropriate level of abstraction. c.f. (Domain) Space Based Architecture is kind of SOA meta-pattern.
In regard to Authorisation, I recommend following the service approach, use a distribute directory services system like open LDAP, and note that is entirely reasonable for service provides and users to have their own credentials and you can use Public-Private keys for signing messages.
The main suggestion is study and learn from experience of others:
http://www.soapatterns.org/
http://martinfowler.com/eaaCatalog/
SOA doesn't forces to use XML.
Currently web technologies dominate, and define future.
So we in my company selected JSON RESTful services as foundation. And SOA as principles.
There is no sense to suggest languages, because the purpose of SOA and good implementation is
- to enable any language or framework to be used
(FYI we use Java with Spring MVC-based web-services, Node.js, PHP)
The web service endpoint usually is defined in an early stage of a project. Since it follows the "contract first" principle, it shouldn't be changed after communicated to client systems.
Therefore, it is vital to label the web service in a good way.
How would you label web services?
e.g.
http://my.domain.com/businessProcess/services/concreteServiceName
Other ideas?
See this question as a poll... Feel free to vote for the best idea.
We decide on names by talking to the developers, business guys, and support guys. We formed a committee called the "interface control committee", and we approach it kind of like you described in the question. We want service names to be descriptive, reflect the processes they support, and fit the needs of the technical and business stakeholders.
When we have ICC meetings, we also talk about schemas and how they should be developed. The business guys are key in this as well since they know what data they want to expose and why.
KA
I would include a version number in the URLs.
If you are going to start the development of an API for your web application. Is there any kind of guidelines, best practices or standard to build web services. I have seen a few discussions in this topic and I will like to get more information.
At least get pointers on where to get the information.
Thanks in advance.
There exists a wide variety and latitude regarding "web services". I find it useful to make explicit note of what we are talking about:
web = transported over HTTP(S)
service = remote procedure call (RPC)
Note that the HTTP(S) portion of this merely specifies the transport medium, but not the content. Also note that the RPC portion of this merely specifies the behavior (essentially invoking remotely a named function with arguments that returns a result) but not the content.
A critical question that arises is whether you control both sides of the communication. If so, but especially if not, you need to be concerned about interoperability.
SOAP is a standard for implementing a web service that specifies using specificly-formatted XML for the content of the request and response. It is VERY heavy, and there are still problems with interoperability across various implementations.
There are lots of custom implementations, most of which are lighter, but you will almost certainly have interoperability issues.
Since any form of content can potentially be used to achieve a web service, I recommend picking something that is able to handle complex content (to varying degrees), standardized, lightweight, and robust.
I am recently leaning towards JSON for the content format. I recommend considering the same, especially if you are considering implementing AJAX.
Best wishes.
API 101
I am pasting this URL as a close approximation of the possible answer. Since I did not get any other answer, I think this is as close as it gets.
I will like to have more detail best practice outline, if someone find something better, let me know to mark their answer as accepted.
If you could answer some of these questions, you might get a more satisfactory answer.
who is the audience that will be consuming the the service?
What types of client technologies will be consuming the service
what assumptions/restrictions can you put on them (platforms, tooling, skill
set)?
How broad is you API - how many methods will it expose?
Is security a consideration - how secure do you need to be?
Do you need to support transactions?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Attended an interesting demo on REST today, however, I couldn't think of a single reason (nor was one presented) why REST is in anyway better or simpler to use and implement than a SOAP based Services stack.
What are some of the reasons Why anyone in the "real world" use REST instead of the SOAP based Services?
Less overhead (no SOAP envelope to wrap every call in)
Less duplication (HTTP already represents operations like DELETE, PUT, GET, etc. that have to otherwise be represented in a SOAP envelope).
More standardized - HTTP operations are well understood and operate consistently. Some SOAP implementations can get finicky.
More human readable and testable (harder to test SOAP with just a browser).
Don't need to use XML (well you kind of don't have to for SOAP either but it hardly makes sense since you're already doing parsing of the envelope).
Libraries have made SOAP (kind of) easy. But you are abstracting away a lot of redundancy underneath as I have noted. yes in theory SOAP can go over other transports so as to avoid riding atop a layer doing similar things, but in reality just about all SOAP work you'll ever do is over HTTP.
RESTful services are much simpler to consume than SOAP based (regular) services. The reason for this is that REST is based on normal HTTP requests which enables intent to be inferred from the type of request being made (GET = retrive, POST = write, DELETE = remove, etc...) and is completely stateless. On the other hand you could argue that it is less flexible as it does away with the concept of a message envelope that contains request context.
In my experience SOAP has been preferred for services within the enterprise and REST has been preferred for services that are exposed as public APIs.
With tools like WCF in the .NET framework it is very trivial to implement a service as REST or SOAP.
Some relevant reading:
Amazon Web Services Blog: REST vs SOAP
Dare Obasanjo writes often about REST
I'll assume that when you say "web services" you mean SOAP and the WS-* set of standards. (Otherwise, I could argue that REST services are "web services".)
The canonical argument is that REST services are a closer match to the design of the web - that is, the design of HTTP and associated infrastructure. Thus, using a REST service will be more compatible with existing web tools and techniques.
Of course, once you drill into specifics, you find out that both approaches have strengths in different scenarios. Is it those specifics that you're interested in?
The overhead isn't that important as good architecture.
REST isn't a protocol it is an architecture that encourage good scalable design.
It is often chosen because too much freedom in RPC can easily lead to a poor design.
The other reason is predictable cost of RESTful protocols over HTTP because it can leverage existing technologies (mainly proxies).
RPC initial cost is quite low but it tend to increase significantly with load intensification.
REST is implementation-agnostic and much more transparent, and this makes it great for public APIs, especially for big websites like Flickr, Amazon or Digg that are using their APIs as marketing tools and really want people to consume their data. They don't want to be hand-holding 1000s of novice developers who are trying to debug their scripting language of choice's buggy SOAP library.
Versus SOAP and WSDL, which are better for internal applications, where you have drop-in libraries and known clueful people on both ends. (And you maybe don't have to care about things like Internet-scale load-balancing, HTTP caching etc.) Then you get APIs that are self-documented, preserve types etc. with zero work.
Got to read Roy Fielding's most excellent dissertation on the topic. He makes an excellent case and was definitely WAY ahead of his time when he wrote it (2000).
Steve Vinoski's blog and his latest articles are definitely worth perusing. He's a former CORBA guru, who wrote probably the best book on the subject with Michi Henning, "Advanced CORBA® Programming with C++". However, he has since seen the error of his client/server ways, and now swears by REST.
REST allows your non-mutating operations (that generally use the GET verb) to be cached. That is, cached by the client and/or cached by proxies. This can be a huge win!
REST is basically just a way to implement web services. It is just a way to use HTTP correctly to query the web services you are trying to hit.
http://www.xfront.com/REST-Web-Services.html
http://en.wikipedia.org/wiki/Representational_State_Transfer
It is super simple and slim. You could do it with browser via http verb: GET.
I haven't find a browser can manually do generic http POST request easily
Here's one data point: Amazon offers its APIs in both REST and SOAP formats and 85% of the usage is REST.
REST is easier to implement, easier to understand and higher performance.