I have three headers A,B,C here A is always mandatory and either B or C should be present only one at a time in request.
How to implement in raml 1.0
It doesn't look like RAML can validate that kind of conditions. About headers the RAML specification only says:
the value of the headers node MUST be a map, specifically a
properties declaration. Each property in this declaration object is a
header declaration. Each property name specifies an allowed header
name. Each property value specifies the header value type as a type
name or an inline type declaration.
Assuming that you are implementing this RAML API in Mule runtime with APIKit then you will need to implement the restriction in the body of the flow.
Related
Swagger by default supports application/json as Content type. And if I want to add other Content types then "produces" or "consumes" fields needs to updated in the swagger JSON file. Client may send any type of Data. Is there a way to support any Content type (remove the validation for Content type or regex like *) in swagger
As far as I have worked on go-swagger, you will have to mention in the swagger-spec file and generate the code again in order to do that. You can use / to describe that the endpoint can generate all type of data. But you can not modify it after you have generated the code using go-swagger.
You can directly modify the generated files but it's not recommended.
I am using the Sling MimeTypeService in order to get an appropriate extension for a given file & trying to override a default extension with my own.
E.g. if I had a method:
#Reference
MimeTypeService mimeTypeService;
public void getPlainTextAsDiff() {
mimeTypeService.registerMimeType("text/plain", ".diff");
mimeTypeService.getExtension("text/plain"); //returns ".txt"
}
This returns ".txt" rather than ".diff", ignoring the first line of the method.
This also seems to be inline with the documentation:
A MIME type may be mapped to multiple extensions (e.g. text/plain to
txt, log, ...). This method is expected to returned one of those
extensions. It is up to the implementation to select an appropriate
extension if multiple mappings exist for a single MIME type.
[My emphasis]
I'm wondering if it's possible to circumvent this somehow, e.g. deregistering a mime-type or ranking those available, so that in the case above "diff" would guaranteed to be returned?
You can extend mime type mappings by providing MimeTypeProvider services, but looking at the MimeTypeServiceImpl code it looks like those are not sorted by service ranking. If I'm correct, you won't have a way to prioritize you MimeTypeProviders. You might want to experiment with this and submit an enhancement request or patch.
After reading MSDN-XAML Namespaces and MSDN-Understanding XAML Namespaces, I still do not understand the purpose of having a Qualified Name (QName).
Take the following namespace declaration as an example:
xmlns:x='http://www.w3.org/1999/XSL/Transform'
x is the prefix short for the full URI (in this case, an URL) : http://www.w3.org/1999/XSL/Transform. Then there is this QName called xmlns. The definition for QName in mdsn is:
This complete name including the prefix is the lexical form of a
qualified name (QName):
What's that supposed to mean and why is it there since thet statement already has a locator and a prefix to identify the namespace and its names to be used?
I think more than this being an XAML question it is just an XML namespace question.
The xmlns attribute (a special attribute) is just the attribute used in XML to define a namespace. It says "here comes a namespace declaration". If you do not add a prefix, then you are telling it to set the namespace that is the value of the attribute as the default namespace for the page. If you omit in completely the default namespace is then assumed to be the value of the attribute (after the = and between the quotes).
XAML is XML and chooses to use the XML mechanism for declaring namespaces. I guess they could have created their own mechanism for doing it but since they didn't, if you added your namespace as you hint at in your question, without the xmlns:, the app processing the XML (the .NET framework in this case, parses the XAML file) would not know you were trying to define a namespace; it would think you were adding an attribute called "x" to the element it was defined in (which would most likely not be an attribute that is defined for that element).
For more about XML namespaces
http://www.w3.org/TR/REC-xml/
http://www.w3schools.com/XML/xml_namespaces.asp
http://en.wikipedia.org/wiki/XML_namespace
Can someone please explain these functions:
RequestHandlerComponent::renderAs()
RequestHandlerComponent::respondAs()
RequestHandlerComponent::setContent()
It feels slightly redundant to have all three of them (as public methods anyway). If I want to respond to a request with a PDF file, does that mean I'd have to call all three functions? How should I use these in my controller?
They're all different. From the API Docs:
renderAs
Sets the layout and template paths for the content type defined by $type.
I.e. more or less a shortcut for $this->layout = '...' and $this->render(...).
respondAs
Sets the response header based on type map index name. If DEBUG is greater than 2, the header is not set.
Outputs header(...).
setContent
Adds/sets the Content-type(s) for the given name. This method allows content-types to be mapped to friendly aliases (or extensions), which allows RequestHandler to automatically respond to requests of that type in the startup method.
Doesn't actually do anything to the output, just allows you to add new types that are not defined by default.
For outputting a PDF (assuming you have it as a file already) you should actually use a Media View.
For example, the WPF namespace is:
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
If I define my own namespace, should it also start with http? Isn't http misleading?
Namespaces doesn't have any meaning in their value, except for that value to be unique to avoid nameclashing. This is why you see a lot of companies putting in the URL for their own website as the namespace. URLs serve the same purpose, to be unique. Over the years it's just become good practice to use an URL, because if everyone does that, no nameclashing should occur :)
The W3C Document defining XML Namespaces says (quoting) :
Definition: An XML namespace is
identified by a URI reference
[RFC3986]
And RFC 3986 says (quoting) :
1.1.1. Generic Syntax
Each URI begins with a scheme name,
as defined in Section 3.1, that
refers to a specification for
assigning identifiers within that
scheme.
So I guess using http:// is what's closest to the standard -- as HTTP is the most common scheme used on the net.
In addition, as there can be only one owner for a domain name, it allows each company to use it's URL in its namespaces.
Another common way instead of using a URL starting with http:// is to use a Uniform Resource Name whose format is defined by RFC2141.
Such namespace identifiers are e.g. used by ODF (OpenDocument Format):
urn:oasis:names:tc:opendocument:xmlns:office:1.0
urn:oasis:names:tc:opendocument:xmlns:style:1.0
urn:oasis:names:tc:opendocument:xmlns:text:1.0
From this article at W3Schools:
"The namespace URI is not used by the parser to look up information. The purpose is to give the namespace a unique name. However, often companies use the namespace as a pointer to a web page containing namespace information. Try to go to http://www.w3.org/TR/html4/."
It is a reliable way to create a readable globally unique identifier. It may or may not be to a valid URL with more information.