I am not an expert in SOAP, but from my knowledge SOAP is just an HTTP request formatted in XML in order to supply structured data.
I need to implement a simple API with a list of parameters.
I proposed using a simple REST interface, but I have been told that SOAP is more secure.
Any ideas on this topic?
My guess would be that you have been told SOAP is more secure because of the existence of various standards that relate to security:
http://en.wikipedia.org/wiki/WS-Trust
http://en.wikipedia.org/wiki/WS-Security
http://en.wikipedia.org/wiki/WS-SecureConversation
http://en.wikipedia.org/wiki/WS-Federation
Most REST implementations are based on HTTP which has Basic Auth, Digest Auth, SSL and OAuth as security related specs. Which is more secure is topic that is could be debated forever!
An important question is does your service need something more secure than online banks use? HTTPS seems to be sufficient for them, and they are a pretty big target.
No, it's not.
I can only guess why would anybody think the API flavor has any relevance in security, or safety (not the same thing, and it's not clear which one is referred to); it might be because the common misconception that REST means simply exposing your data objects. If that were the case, such an approach would surely be utterly unsafe! (in any meaning of the word)
Related
HTTP content negotiation can be used to make client and server agree on a data format and language. Maybe you're interested in my previous question (Is HTTP content negotiation being used by browsers and servers in practice?) but it's not necessary to read.
Does this concept really make sense when developing an HTTP-based API? (An API is a web service that is not used by end users. It's called exclusively in a programmatic way.)
An alternative to content negotiation are "regular" parameters (e.g. http://example.org/myService?someParam=1234&lang=en&format=xml).
Most client-side frameworks make it very easy to call a web service and send parameters. It is often much harder to configure special HTTP headers. It seems to be more work to use HTTP content negotiation.
At the same time there is no need to negotiate. The client will be programmed in such a way that it knows what formats and languages are available. Therefore, it will only make valid calls in this regard and get exactly what it wanted.
If the server wants to decline a call it can send an application-level error instead of an HTTP error. Application-level errors are, in my experience, easier to handle. You need that code anyway. You don't necessarily ever need to interpret HTTP errors. You can just treat all of them as a generic failure.
Content negotiation seems to fit the REST philosophy well but I'm more interested in concrete costs and benefits.
In what way is HTTP content negotiation superior to just adding an API parameter?
I haven't worked with many frameworks that tout the ability to work with any RESTful API out-of-the-box. Primarily, because it is just not feasible to communicate with any possible RESTful implementation without a very broad feature for configuration, which the ones that I have seen do not have. However, that is the fault of the framework, not the API.
Working with request/response headers is essential for communicating with any well-designed RESTful API. Headers are useful for sending information like access tokens and message body signatures, and receiving information like collection size and pagination details. Why not use a system that already exists for exactly the purpose of negotiating content format? Using the full extent of the existing HTTP specification is exactly what REST is about.
About HTTP errors... why would you treat them all the same? A 404 should be handled much differently than a 400 which should be handled much differently than a 409. Either I misunderstood you, or I think you are missing some of the key aspects of REST.
Does this concept really make sense when developing an HTTP-based API? (An API is a web service that is not used by end users. It's called exclusively in a programmatic way.)
Yes, it still does.
The client will be programmed in such a way that it knows what formats and languages are available.
That sounds like you are coupling the client to a specific API, which somewhat misses the point. The client should absolutely understand those media-types that it itself understands, but why should it know what is available?
Fielding himself wrote:
REST is intended for long-lived network-based applications that span multiple organizations.
Now, specifically with regards to negotiation, Fielding had an interesting observation that in most cases, you'll want each negotiated resource to have it's own identifier.
Thus http://example.org/myService?someParam=1234, with appropriate headers, would return the representation of http://example.org/myService?someParam=1234&lang=en&format=xml. That might be via a redirect (which seems to be the mechanism Fielding thought most suitable in 2006), or it might simply return the negotiated representation at once, with metadata providing the identifier of the returned representation
Note that the latter request is still stateless -- the server shouldn't respond any differently if you negotiate your way to the specific resource, or just as for the one you want immediately. You might, for instance, end up negotiating with one server, and being re-directed to the representation you want on a completely different host.
That means that the servers can't really distinguish the clients that negotiate from those that don't. You can simply wire the identifier of the negotiated resource directly into your client, and it will "work".
In what way is HTTP content negotiation superior to just adding an API parameter?
Standardization. With content negotiation, my generic client doesn't need to know anything about the spelling conventions used by your api. The intermediary components (example: caches) don't need to know about your spelling conventions either.
Does this concept really make sense when developing an HTTP-based API? (An API is a web service that is not used by end users. It's called exclusively in a programmatic way.)
Coming back to this point: REST is a collection of architectural constraints selected to induce particular properties. In other words, we're making tradeoffs. If the advantages of long lived clients aren't valuable in your circumstances, then the architectural constraints that support that use case aren't going to be pulling their full weight.
Lately I have been reading a little bit about HATEOAS implementation in a HTTP JSON REST API(since I making one), and I understand the general concept of links and actions and so on and that there are many some different formats defined such as HAL, JSON API, etc.
What I don't understand yet is what the relationship between HATEOAS/REST and authentication is, or to make it into a more concrete question, what type of authentication should a "proper" HATEOAS/REST API use?
Obviously, it should be stateless, like a JWT token or something like that, but is there any standard and/or rules/guidelines or is authentication totally different subject?
Edit:
To clarify even further, my problem is not that I am having problems picking what authentication to implement, but that I do not know what is required from the API authentication-wise in order to be able to call it a REST/HATEOAS API.
So the (hypothetical) scenario would be: Create an API that can be said to be REST/HATEOAS in every sense of the word and get $1,000,000. Make one minor protocol-violating mistake and get $0. Meaning, the objective is not to do what makes the most sense, is the most efficient or what benefits the developers and/or users, but just to be 100% REST/HATEOAS beyond the shadow of a doubt.
Like you said, you should look at authentication in an independent manner.
It's true that token-based authentication systems implemented used by-value tokens do fit well in the stateless world of HTTP based API's so this could possibly be the recommendation to give for most common scenarios. However, you should look into the particular requirements of your scenario to reach a final decision, maybe there's a simpler option available like API keys.
Have in mind that if you choose a token-based approach there's still a lot to consider thereafter. Your API won't be of much use if you don't define a way for applications to obtain access tokens and there are many ways you can go about this, for example:
You could roll your own system and define your own processes around how the tokens are obtained and then used by the API in order to perform authentication
⤷ (not recommend, time consuming and easy to get something wrong)
Implement an identity provider/authorization server system compliant with available authentication standards like OpenID Connect and OAuth 2.0
⤷ (time consuming and complex, but by following standards you're less likely to mess up and you'll also gain interoperability)
Delegate the authentication to a third-party authentication provider like Auth0
⤷ (easy to get started, depending on amount of usage it will cost you money instead of time)
Disclosure: I'm an Auth0 engineer.
Considerations:
First of all, I'm looking for a programmed/automated solution, not a -personal- solution. I'm afraid that this question has not a direct answer because technology, so I'll check any workaround to make this validation.
Scenario:
I've a public RESTful service that my customers (third party applications) can consume.
It has authentication basic (in the header) and the POST has a parameter that contains a cyphered string in SHA-256 with the data sent in the other parameters, in order to validate the data.
This cyphered string is made by a hash-key provided by me, for every customer, because some customers are competitors between them.
Anyway...
Problem:
Some customers are hitting the service directly from ajax, instead using a server-side http client. They are using the hashkey and the user/pass inside a javascript and beware my recommendations, there were no changes in their code. Because of this, we are not enabling them in our production environment.
Question:
It's possible (and how can I do it?) validate if the call is from server-side without checking the URL referer?
Just as comment, I'm using Web Api 2.2 in C#, but I think I could handle making the code myself, so any answer without code will be useful anyway.
I'm afraid that there is not exists any answer, because the clients are the same, but any some workaround or idea will be preciated.
Sorry for my english and my poor knowledge in HTTP clients.
If you could describe why it is a problem that customers are using ajax - would be easier to guess general solution. For example you can create registration service where your customer must specify their IPs so you can whitelist them, or you can create client auth library which all customers should use.
The problem
We are building an SOA with a RESTful approach to the services. Once the systems are in production we will have many clients consuming the interface including internal and 3rd party systems.
We would like to be able to consume and echo in the response information provided by the client application such as: -
Session Id - Could be a Java EE session id or anything client specific, this is useful for the support team and debugging client issues to trace them through all our systems.
Transaction Id - A unique identifier for the request that we can echo back to the client to aid the client in request/response correlation if they invoke the service asynchronously or if we implement an 202 Accepted style long running process.
Potential solutions
So sticking to the RESTful constraints would suggest we need to utilise HTTP to implement this and there are several options we could implement.
Pragma header - implement extension-pragmas for transaction-id, session-id, etc. This seems like purist of solutions as it utilises a standard HTTP header although I would be concerned it became a dumping ground for everything we can't be bothered to think about properly.
X-My-Header - custom headers for each field we require. May be stripped by proxies, not core HTTP so feels anti-rest
In query string or XML/JSON representations - Add the fields to all our resources. Because it's an operational parameter it feels like it should be provided as metadata rather than on a resource.
Cookies - use Cookie and Set-Cookie to hold custom key-values; useful in the case of session ids as most implementations use cookies already. Would have to re-send every time to support client side correlation which kind of defeats the point of using a cookie.
The answer
Is there any precedent for this? Are we mad? Is there something obvious I am missing in all my research? Does no-one actually care how they will support their services once they are deployed? Should I just shut up and go away?
I'm hoping someone can help.
P.S. sorry if this is a bit of an essay, the advice did say "be specific"....
Oh, this is a pain. I've been there too.
Well, the idea with metadata for transactions, sessions etc. is a good idea. For logging, at least.
The problem is to setup something that is compliant with various corporations policies and SOA infrastructure.
There is a tradeof between best design and maximum interopability in the case of HTTP.
The safe path is to encode the metadata in the message itself. Not very nice, and such a solution ends up looking a bit like SOAP where you have an envelope with headers for all messages.
I ended up using an X-header for information such as transaction id. However, as you mentioned, proxies/b2b-gateways etc. might strip headers, it's not obvious that you can retreive them with all appointed development frameworks, COTS applications etc. So if you do like this, you should avoid make the metadata mandatory to get a solution running - just "nice to have".
Cookies are nothing but pain. They might be annoying or sometimes even useful with browser interaction, but in a SOA scenario, it will be bad idea. Many things can go wrong and it's a pain to debug cross organisations.
I would also avoid using query strings along with POST or PUT data. It's possible according to the HTTP specs. but not when it comes to implementation in random framework.
You can use a GUID and let the client generate it and pass it as part of any request that starts the workflow/business process. This GUID can be used to correlate across multiple components participating in the workflow.
I mean, really, what is the point of SOAP?
Web services have been around for a while, and for a while it seemed that the terms 'SOAP' and 'Web service' were largely interchangeable. However SOAP always seemed unwieldy and massively overcomplicated to me.
Then REST came along, and suddenly web services made sense.
As Joel Spolsky says, give a programmer a REST URL, and they can start playing with the service right away, figuring it out.
SOAP is obfuscated behind WSDLs and massively verbose XML, and despite being web based, you can't do anything as simple as access a SOAP service with a web browser.
So the essence of my question is:
Are there any good reasons to ever choose SOAP over REST?
Are you working with SOAP now? Would it be better if the interface was REST?
Am I wrong?
As Joel Spolsky says, give a programmer a REST URL, and they can start playing with the service right away, figuring it out.
Whereas if the service had a well specified, machine readable contract, then the programmer wouldn't have to waste any time figuring it out.
(not that WSDL/SOAP is necessarily an example of good implementation of a well specified contract, but that was the point of WSDL)
Originally, SOAP was a simple protocol which allowed you to add a header to a message, and had a standardized mapping of object instances to XML structures. Putting the handling metadata in the message simplified the client code, and meant you could very simply persist and queue messages.
I never needed the header processing details when I built SOAP services back in 2001. This was pre-WSDL, and it was then normal to use GET for getting information and queries (no different to most applications which claim to be REST; REST has more in terms of using hyperlinks for service discovery) and POST with a SOAP payload to perform actions. Those actions which created resources would return the URL of the created resource to the client, and the client could then GET the resource. I think it's the fact that WSDL made it easy to think only in terms of RPC rather than actions which create resources which made SOAP lose the plot.
The way I see it, SOAP might be more "flexible", but as a result it's just way too complicated (you mentioned the WSDL, which is always a stumbling block to me personally).
I get REST. It's simple. The only downside I might see is that you are limiting yourself to those 4 basic actions against a single resource, which might not exactly fit the way you view your data.
The topic is well-discussed in Why is soap considered to be thick.
While doing some research to understand some of the answers here (especially John Saunders') I found this post http://harmful.cat-v.org/software/xml/soap/simple
SOAP is more insane than I thought...
The point of WSDL was auto-discovery. The idea was that you wouldn't have to write client code, it would be auto-generated.
BTW. next step beyond WSDL are Semantic Web Services.
If you don't need the features of the WS-* series of protocols; if you don't need self-describing services; if your service cannot be completely described as resources, as defined by the HTTP protocol; if you don't like having to author XML for every interaction with the service, and parse it afterwards; then you need SOAP.
Otherwise, sure, use REST.
There's been some question about the value of a self-describing service. My imagination fails me when it comes to imagining how anyone could fail to understand this. That's on me. Still, I have to think that anyone who has ever used a service much more complicated than "Hello, world" would know why it is valuable to have someone else write the code that accepts parameters, creates the XML to send to the service, sends it, receives the response, then turns that back into objects.
Now, I suppose this might not be necessary when using a RESTful service; at least not with a RESTful service that does not process complex objects. Even with a relatively simple service like http://www.earthtools.org/webservices.htm (which I've used as an example of calling a RESTful service), one benefits from understanding the structure of the returned data. Even the above service provides an XML Schema - it unfortunately doesn't describe the entire response. Given that schema one still has to manually process the XML, or else use a tool to produce serializable classes from the schema.
All of this happens for you when the service is described in a WSDL, and you use a tool like "Add Service Reference" in Visual Studio, or the svcutil.exe program, or I-forget-what-the-command-is-in-Eclipse.
If you want examples, start with the EarthTools services, and go on to any other services with more complicated messaging.
BTW, another thing that requires self-description is description of the messaging patterns and protocols supported by the service. Perhaps that's not required when the only choices are HTTP verbs over HTTP or HTTPS. Life gets more complicated if you're using WS-Security and friends.
I find that SOAP fits in most appropriately when there is a high probability that a service will be consumed by corporate off the shelf (COTS) software. Because of the well specified contract employed by SOAP/WSDL most COTS packages have built in functionality for consuming such services. This can make it easy for BPM/workflow tools etc. to simply consume defined services without customization. Beyond that service use case REST tends to be my goto web service implementation for applications.
Well it appears now that the WSI agree that SOAP no longer has a point as they have announced they will cease to exist as an independent entity.
Interesting article about the announcement and some commentary here: http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm
Edited to be completely accurate in response to John Saunders.
I think SOAP appeals to the Java and .net crowd who may be more familiar with the old CORBA and COM and less familiar with internet technologies.
REST also has one major drawback: there is very little guidance on how to actually implement such a system. You will find significant variations on how many of the public RESTful APIs have been designed. In fact many violate key aspects of REST (such as using GET for manipulation or POST for retrieval) and there are disagreements over fundamental usage (POST/GET vs POST/GET/PUT/DELETE).
Am I wrong?
"You're not wrong, Walter, you're just... :)"
Are there any good reasons to ever choose SOAP over REST?
SOAP, to my understanding adheres to a contract, thus can be type checked.
SOAP is a lightweight XML based structured protocol specification to be used in the implementation of services . It is used for exchanging
structured information in a decentralized, distributed environment. SOAP uses XML technologies for exchanging of information over any transport layer protocol.
It is independent of any particular programming model and other implementation specific semantics. Learn More about XML
SOAP Messaging Framework
XML-based messaging framework that is
1) Extensible : Simplicity remains one of SOAP's primary design goals. SOAP defines a communication framework that allows for features such as security, routing, and
reliability to be added later as layered extensions
2) Inter operable : SOAP can be used over any transport protocol such as TCP, HTTP, SMTP. SOAP provides an explicit binding today for HTTP.
3) Independent : SOAP allows for any programming model and is not tied to Remote procedure call(RPC). SOAP defines a model for processing individual, one-way messages.
SOAP also allows for any number of message exchange patterns (MEPs) .Learn more about SOAP