I've been trying to find a simple explanation on the web on this header.
What is its use?
When do we need it?
What does it do?
What does it mean?
and so on...
I know this is pretty simple but I've been looking for a well explained answer regarding this header online for more than an hour.
Action header describes what operation must be invoked on the service. MustUnderstand is general attribute for headers used in SOAP messages. Once header is marked with this attribute and either service or client doesn't have "handler" for that header (doesn't understand what to do with header) the processing should fail (should not must - for example intermediaries don't fail if they don't understand a header because the header doesn't have to be targeted to them). Once the Action header is used it is used together with MustUnderstand attribute.
Related
I have an API that will delete a resource (DELETE /resources/{resourceId})
THE above API can only tell us to delete the resource. Now I want to extend the API for other use cases like taking a backup of that resource before deleting or delete other dependant resources of this resource etc.
I want to extend the delete API to this (DELETE /resources/{resourceId}?backupBeforeDelete=true...)
Is the above-mentioned extension API good/recommended?
According to the HTTP Specification, any HTTP message can bear an optional body and/or header part, which means, that you can control in your back-end - what to do (e.g. see what your server receives and conventionally perform your operation), in case of any HTTP Method; however, if you're talking about RESTful API design, DELETE, or any other operation should refer to REST API endpoint resource, which is mapped to controller's DELETE method, and server should then perform the operation, based on the logic in your method.
DELETE /resources/{resourceId} HTTP/1.1
should be OK.
Is the above-mentioned extension API good/recommended?
Probably not.
HTTP is (among other things) an agreement about message semantics: a uniform agreement about what the messages mean.
The basic goal is that, since everybody has the same understanding about what messages mean, we can use a lot of general purpose components (browsers, reverse proxies, etc).
When we start trying to finesse the messages in non standard ways, we lose the benefits of the common interface.
As far as DELETE is concerned, your use case runs into a problem, which is that HTTP does not define a parameterized DELETE.
The usual place to put parameters in an HTTP message is within the message body. Unfortunately...
A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request
In other words, you can't count on general purpose components doing the right thing here, because the request body is out of bounds.
On the other hand
DELETE /resources/{resourceId}?backupBeforeDelete=true
This has the problem that general purpose components will not recognize that /resources/{resourceId}?backupBeforeDelete=true is the same resource as /resources/{resourceId}. The identifiers for the two are different, and messages sent to one are not understood to affect the other.
The right answer, for your use case, is to change your method token; the correct standard method for what you are trying to do here is POST
POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.” -- Fielding, 2009
You should use the "real" URI for the resource (the same one that is used in a GET request), and stick any parameters that you need into the payload.
POST /resources/{resourceId}
backupBeforeDelete=true
Assuming you are using POST for other "not worth standardizing" actions, there will need to be enough context in the request that the server can distinguish the different use cases. On the web, we would normally collect the parameters via an HTML form, the usual answer is to include a request token in the body
POST /resources/{resourceId}
action=delete&backupBeforeDelete=true
On the other hand, if you think you are working on an action that is worth standardizing, then the right thing to do is set to defining a new method token with the semantics that you want, and pushing for adoption
MAGIC_NEW_DELETE /resources/{resourceId}
backupBeforeDelete=true
This is, after all, where PATCH comes from; Dusseault et al recognized that patch semantics could be useful for all resources, created a document that described the semantics that they wanted, and shepherded that document through the standardization process.
How to identify operation from xml content posted to WCF Service Url?
Suppose WCF Service Url is http://single.mat.nn.com and client dont want to include operation name in Url.
Problem is to identify operation on the basis of xml content posted .
I am not able to find any solution for this problem. Is it feasible to do configuration in WCF Service that can identify operation method on the basis of xml content posted to WCF Service URL.
One of the scenarios possible in Extending Dispatchers is:
Custom Operation Dispatching. Users can implement dispatching on something other than action – for example, on the body element, or on a custom message property. This can be done using the IDispatchOperationSelector interface.
Implmenting IDispatchOperationSelector will give you access to the incoming message to parse and decide which method you want to forward the request to.
The SOAP web service based on the corresponding method of the SOAPAction field request in the HTTP request. See the screenshot below.
The SOAPAction field and the method section in the request body can view the operation name of the specific request. If you want to recognize this value, we can intercept the SOAP message through the following two interfaces and get the value of the field.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/extending/how-to-inspect-or-modify-messages-on-the-client
https://learn.microsoft.com/en-us/dotnet/api/system.servicemodel.dispatcher.idispatchmessageinspector?view=netframework-4.8
these two interfaces could capture the SOAP message during the communication. We could retrieve the field value and modify it.
Feel free to let me know if there is anything I can help with.
I'm writing a fairly generic webapp that I want to be JAX-RS "pure", though I'm developing using Jetty and CXF. I want to do something extremely simple, I want for ALL HTTP responses a header added (not just for the methods I'm writing code for, even auto-handled 415 responses).
Solutions for How do i modify HTTP headers for a JAX-WS response in CXF? seem overly complex (and specific for CXF's implementations of JAX-RS)for just needing to add:
MyServerVersion : 1.0
to every response.
The standard way to do this is with a ContainerResponseFilter. See Chapter 6: Filters and Interceptors of the JAX-RS specification.
You'll want to add your header to ContainerResponseContext#getHeaders(). See this question for an example.
Thanks for answer above, I summarized what I did in a blog post and it gives some background and context for the Accept-Post response header I was working with and code samples.
We are using an authentication string (guid) for client identification in our wcf services
and for database lookups.
We dont want to add this to every messagecontract.
Is there a way to do this in wcf?
Regards,
Rune
The best and typical way is to add this to a header in your WCF message - and that would be perfect in a message contract.
Why do you not want to add it to the message contract??
WCF typically encourages a "per-call" methodology - you send all necessary info with your call, each and every call that is. It is discouraged to have any kind of "state" that lingers around between calls.
So again: why not just include your authentication string as a header in every message? That's the preferred way of doing things these days.
UPDATE:
Check out Nicholas Allen's blog post on Adding Headers to a Call. Besides adding them to the message contract, you could also check out the Message Inspector sample he links to, which creates a message inspector that automagically adds those header entries to each outgoing call. No code clutter, no mess, nothing - just works.
I am using WCF as a client for a java web service. I have not control over the server side.
In the response I get from the web service there is no xmlns attribute on the first element inside the soap headers. Because of this WCF returns null as the result of web service call.
Apart from the missing xmlns the response is perfect and if I add the xmlns using fiddler then everything works as expected. I don't know enough about SOAP to know if the xmlns attribute is really required.
Is there a way to avoid this problem, either getting WCF to ignore the missing xmlns attribute or even a hook that would allow me to manually munge the response before it gets to WCF?
This appears to be a pretty old question, so I'm not sure if you ever addressed this. If you are working with a WCF client for a Java Axis service, you will find that you will need to get used to using MessageInspectors to override the behavior of the request and response.
Using the AfterReceiveReply method you should be able to copy the original message and alter the headers. Also check out Step 5 from this MSDN article.
You can't alter the response headers directly in this method as far as I can see, because they are read-only, therefore copying and then replacing the reply with a doctored version is the only way I can think of to correct the missing namespace.