Is there any accepted naming convention for custom http headers in an in-house web application?
in-house in the strict sense means that requests with this header will never be transmitted over the public internet. in-house in a liberal sense means that while requests may be transferred over the public internet the server endpoint will always be a machine under control of a specific vendor.
i am aware of this SO article and the RFC 6648.
However, the reasoning forwarded in the latter reference does not quite convince me as it says:
2. SHOULD employ meaningful parameter names that they have reason to
believe are currently unused.
3. SHOULD NOT prefix their parameter names with "X-" or similar
constructs.
Well, X-<meaningful_name> conveys the semantics suggested by <meaningful_name> + the information that this header has neither been assigned by nor registered with an official standard maintaining authority, so the items 2., 3. appear a bit contradictory.
Of course, I could use other monikers like Vnd- or a company/product name prefix or even a customary term like Foo-. the arguments against the X- prefix would still apply, however.
On the other hand, just using a 'meaningful name' invites future collisions with the same term being endorsed by an official standard or some other company whose products will become part of the processing pipeline.
ps:
apologies if this question is considered overly unspecific. I'll be happy to move it to some other more suitable venue.
Yes, there is a accepted naming convention.
VND.{domain}.{key}
Example: VND.wreckingballmedia.com.runtime = 102ms
You can read the official recommendation here: https://www.rfc-editor.org/rfc/rfc6648
It basically says that everyone thought "X-MyNonStandardHeader = Value" was a good idea but there are still naming collisions. It says you might get away with UUIDs or something, but, they recomend the VND.domain.key format.
Related
What are the benefits of the "Convention over Configuration" paradigm in web development? And are there cases where sticking with it don't make sense?
Thanks
Convention states that 90% of the time it will be a certain way. When you deviate from that convention then you can make changes...versus forcing each and every user to understand each and every configuration parameter. The idea is that if you need it to differ you will search it out at that point in time versus trying to wrap your head around all the configuration parameters when it often times has no real value.
IMHO it always makes sense. Making convention the priority over explicit configuration is ideal. Again if someone has a concern, they will force themselves to investigate the need.
I think the benefit is simple: No configuration necessary. You don't need to define locations for this-or-that type of resource, for example, for the app/framework to find them itself.
As for cases where it does not make sense: any situation where it will be fairly frequent that alternative configurations would be required, or where it makes sense that a developer/admin would need to 'opt-in' to some behavior explicitly (for example, to prevent unintended and unexpected side-effects that could have security implications).
The benefit of convention over configuration paradigm in web development the productivity since you won't be required to configured to set all the rules and there are less decision that a programmer has to make. This is evident when using the .NET Framework.
The most obvious benefit is that you will have to write lesser code. Let's take case of Java Persistence API. When you define a POJO having attributes and corresponding setters/getters, it's a simple class. But the moment you annotate it with #javax.persistence.Entity it becomes an entity object (table) which can get persisted in DB. Now this was achieved by just a simple annotation, no other config file.
Another plus point is, all your logic is at one place and in one language (i.e. you get rid of separate xml).
I think this wikipedia article has explained it very well:
Convention over configuration (also known as coding by convention) is
a software design paradigm used by software frameworks that attempts
to decrease the number of decisions that a developer using the
framework is required to make without necessarily losing flexibility.
The concept was introduced by David Heinemeier Hansson to describe the
philosophy of the Ruby on Rails web framework, but is related to
earlier ideas like the concept of "sensible defaults" and the
principle of least astonishment in user interface design.
The phrase essentially means a developer only needs to specify
unconventional aspects of the application. For example, if there is a
class Sales in the model, the corresponding table in the database is
called "sales" by default. It is only if one deviates from this
convention, such as the table "product sales", that one needs to write
code regarding these names.
When the convention implemented by the tool matches the desired
behavior, it behaves as expected without having to write configuration
files. Only when the desired behavior deviates from the implemented
convention is explicit configuration required.
I got a query while developing rest service.
As per the REST design, GET is to read , PUT or POST are to create or update based on scenario , DELETE is to delete the resources.
But technically, Can't we perform a create or delete operation in GET call.
i.e. It is up to client way of calling by using specified URL pattern and required response type to hit the exact method in the service class of REST application. But why can't we perform a delete or create of some data in the GET service.
so my question is the DELETE or CREATE technically not possible in GET service or is it a rule to adhere to REST principles.
so my question is the DELETE or CREATE technically not possible in GET service or is it a rule to adhere to REST principles.
The latter. It is only a convention to use the DELETE HTTP method for delete operations. However using the GET HTTP method for delete operations is a bad idea. Below is a quote from "RESTful Java with JAX-RS 2.0, 2nd Edition" that explains why:
It is crucial that we do not assign
functionality to an HTTP method that supersedes the specification-defined boundaries
of that method. For example, an HTTP GET on a particular resource should be readonly.
It should not change the state of the resource it is invoking on. Intermediate services
like a proxy-cache, a CDN (Akamai), or your browser rely on you to follow the semantics
of HTTP strictly so that they can perform built-in tasks like caching effectively. If you
do not follow the definition of each HTTP method strictly, clients and administration
tools cannot make assumptions about your services, and your system becomes more
complex
so my question is the DELETE or CREATE technically not possible in GET
service or is it a rule to adhere to REST principles?
REST uses standards aka. uniform interface constraint. One of these standards is the HTTP standards which defines the HTTP methods. According to the HTTP standard the GET is a safe method:
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested.
According to the RFC 2119:
SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
For example write can be a side effect by GET, if you want to increase the visitor count by each request.
How the server software (API) is constructed and what 'rules' are applied is somewhat 'arbitrary'. Developers and their product managers could enforce 'rules' such as 'thou shalt not code or support DELETE operations through the GET operation', but in practice, that is not necessarily the main reason POST is chosen over GET. As others have mentioned, there may be assumptions based on the HTTP protocol that other vendors may rely on, but that is a rather complex and not necessarily relevant reasoning. For instance, your application may be built to connect directly to a server application, and another vendor's rules may not apply.
In a simpler example, on the world wide web and due to compliance and other factors, query string has a limited byte length. Because of this, operations that require a lot of data, such as a few very long encrypted data strings that might be needed for a DELETE operation in a database, GET may not be able to pass enough data, so POST may be the only viable option.
Custom built applications using a CuRL library might extend to include other RESTful operations with their intended functionality, but that would be for the benefit of the server API. Coding more operations on the client-side doesn't necessarily make things 'easier', 'faster', or necessarily 'more secure' from the client perspective, but doing so could help manage resources (a bit) on the server side and help maintain compatibility with third party software and appliances.
I'm designing a new API and I'm struggling with some decisions. I've read tons of blogs on SOAP vs REST and I used the popular APIs (Paypal, Amazon, etc.) as my guidelines.
I ended up with 2 endpoints in my API: one for SOAP and one for REST (XML). The SOAP one looks pretty good, but the XML interface looks somewhat strange. I'm calling it "strange" because I ended up with namespaces in some of my tags. For example:
[sample1]
<EnvelopeRequest xmlns:c1='http://foobar/CarrierX'>
<Weight>1.0</Weight>
<PostmarkDate>5/3/2013</PostmarkDate>
<c1:ShippingMethod>Ground</c1:ShippingMethod>
<c1:Notification>a#b.com</c1:Notification>
</EnvelopeRequest>
[sample2]
<EnvelopeRequest xmlns:cs='http://foobar/SpecialCarrier'>
<Weight>1.0</Weight>
<PostmarkDate>5/3/2013</PostmarkDate>
<cs:Shape>Flat</cs:Shape>
</EnvelopeRequest>
The reason the XML interface has namespaces is because it is auto-generated from the class definition (which has some inheritance). We are using WCF btw. That works just fine for SOAP (the WSDL is derived from the same class), because SOAP hides all the ugliness in the client proxies. However, after looking at many REST/XML services, I don't think I've seen namespaces being used too often. This also kinda scares me because I'm thinking that I would love to have a JSON interface in the near future, and JSON doesn't support namespaces.
My decision to make the API SOAP friendly came from the fact that many of our customers use Enterprise solutions which thrive on SOAP. But lately, with the growing popularity of Python and Ruby, which new clients seem to adopt more often, I'm starting to second guess my initial decision. The main thing that bothers me is the namespaces in the XML interface, but is it really an issue? Are namespaces in a REST/XML API such a big no-no that I should change my design?
If I do change my design, then my (2 previous) requests would look like so:
[sample1]
<EnvelopeRequest>
<Weight>1.0</Weight>
<PostmarkDate>5/3/2013</PostmarkDate>
<CarrierX>
<ShippingMethod>Ground</ShippingMethod>
<Notification>a#b.com</Notification>
</CarrierX>
</EnvelopeRequest>
[sample2]
<EnvelopeRequest>
<Weight>1.0</Weight>
<PostmarkDate>5/3/2013</PostmarkDate>
<SpecialCarrier>
<Shape>Flat</Shape>
</SpecialCarrier>
</EnvelopeRequest>
And yes, this would allow me to have a JSON interface in the future.
Removing namespaces would be a problem if by doing so you create the possibility of ambiguity in a given message. Is it possible for someone somewhere to create an EnvelopeRequest message with a Shape element that might be interpreted (by code or by people reading the message) in more than one way? The reason to introduce namespaces is to preclude this possibility. Tools like WCF's auto-generator are not able to answer this question in the general case so they err on the side of caution.
Only you can know the set of possible valid messages. In my experience, it's usually preferable to remove namespaces for the sake of not confusing your users/clients. There are a few reasons why I might change that preference:
I expect my message format to be used widely and intermixed with other formats. (A good example is the Atom syndication format)
I'm using someone else's widely used (and namespaced) format and planning to intermix it with my own (e.g. embedding XHTML inside my message).
I expect to embed a message of a given format inside a message of the same format (e.g. XSLT stylesheets that generate XSLT stylesheets).
In that latter case, you might find it convenient (though not absolutely necessary) to use namespaces to separate the inner message from the message that is carrying it by using different prefixes. I don't think any of these cases apply very often.
I would ponder why you have namespace in the first place, those are some strange payloads.
But, disregarding that, no, the namespaces are not a big deal. Namespaces almost inevitably run afoul with XPath and XSL (since they tend to be namespace aware), but when consuming the document wholesale, a lot of times folks just ignore the namespace component completely, so in the end there's no difference.
I would clean up the namespaces for the sake of cleaning them up semantically, but not necessarily for the sake of the consumers. From a practical stand point, it's not that big a deal.
I want to provide different answers to the same question for different users, based on the access rights. I read this question:
Excluding private data in RESTful response
But I don't agree with the accepted answer, which states that you should provide both /people.xml and /unauthenticated/people.xml, since my understanding of REST is that a particular resource should live in a particular location, not several depending on how much of its information you're interested in.
The system I'm designing is even more complicated than that one. Let's say that a user has created a number of circles of friends, and assigned different access rights to them. For example, my "acquaintances" circle might have access to my birthday, and my "professional" circle might have access to my employment history, but not the other way around. In order to apply the answer from the question I mentioned, I need to have a way of getting all of the user's circles (which I might want to keep secret for security reasons), and then go through /circles/a/users/42, /circles/b/users/42, /circles/c/users/42 and so on, and then merge the results to display the maximum amount of information available. Obviously there's not necessarily a single circle that gets all the information that any of the other circles get. I believe this is tricky enough (note that I probably need to do this with several kinds of objects and that future versions might require a different procedure), but what if I want to impose security restrictions on a particular user despite the fact that he's also in some of my circles? Can that problem even be solved? Even if I refuse to respond to any of the above-mentioned queries and come up with a new one that could give me an answer, it'd still reveal the fact that this specific user is treated differently due to individual access restrictions.
What am I missing here? Is it even possible for me to develop a RESTful web service?
If the conclusion is that the behavior is not RESTful, would this still constitute as a situation where it'd be morally okay to break the REST contract? If so, what are the negative implications? Do I risk proxy caching issues for example?
According to Fielding's dissertation (it really is a great writing):
A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
In other words, if you have a resource that is defined as "the requesting user's assigned projects" and representations thereof accessible by a URI of /projects, you do not violate any constraints of REST by returning one list of projects (i.e., representation) for user A and another (representation) for user B when they GET that same URI. In this way, the interface is uniform/consistent.
In addition to this, REST only prescribes that an explicit caching instruction be included with the response, whether that is 'cache for this long' or 'do not cache at all':
Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable.
How you choose to manage that is up to you.
Keeping that in mind,
You should feel comfortable returning a representation of a resource that varies depending on the user requesting a representation of a particular resource, as long as you are not violating the constraints of a uniform interface -- don't use a single resource identifier to return representations of different resources.
If it helps, consider that the server responds with varying representations of a resource as well -- XML or JSON, French or English, etc. The credentials sent with the request are just another factor the server is able to use in determining which representation to to send in response. That's what the header section is there for.
I agree that the other solution doesn't seem right. It makes the URL structure complicated and more difficult to find the resource. However, if you did REST properly, it shouldn't matter what the URL for the resource is as the server controls it (and is free to relocate it as it sees fit). If your client is really "REST", it would discover the resources it needed through prior negotiation with the server. So the path truly would not matter on the client. I don't like it because its confusing to use - not because of some violation of REST principles.
But that probably doesn't answer your question -
What you didn't mention is your security setup - presumably you are a passing a session token with the request as part of the request header. So your back-end processing should have the ability to tie it to particular set of security constraints. From there, you form the list with whatever business logic you need and return a limited resource based on the user's security tied to the session.
For the algorithm itself, one usually implements a least or most restrictive type algorithm that merges the allowable data into a response (very similar to java realms or Microsoft's user security model).
If the data is structured differently for the restricted/non-restricted case, you could create two different representations of the data and return which ever one the user was authorized to see. The client should be asking for the accepted mime response types anyway, and it would just provide different answers based on the session security in the request header. Alternatively, you could provide optional elements with the representations and fill out the appropriate one base on authorization (although this is a little hack-ee in my opinion).
What is the minimum set of HTTP verbs that a server should allow for a web service to be classed as RESTful?
What if my hoster doesn't permit PUT and DELETE?
Is this actually important, can I live happily ever after with just GET and POST ?
Update: Thanks for the answers folks, Roger's answer was probably best because of the link to the Bill Venners and Elliotte Rusty Harold interview. I now get it.
Yes, you can live without PUT and DELETE.
This article tells you why:
http://www.artima.com/lejava/articles/why_put_and_delete.html
While to true RESTafrians this may be heresy, in the real world you do what you can, with what you have. Be as rational as you can and as consistent with your own convention as you can, but you can definitely build a good RESTful system without P and D.
rp
You can also use X-Http-Verb-Override:DELETE inst. of HTTP DELETE. This is also usefull for Silverlight clients who cant change the HTTP verbs and only support GET and POST...
If you just use GET and POST, it's still RESTful. Your web service may only do things which only required GET or POST, so that's fine.
REST allows for breaking protocol convention if the implementations of the protocol are broken (so that the only non-standard things you do are to get around the broken parts of the implementation). So it is allowable within REST to use some other method to represent generally unsupported verbs like DELETE or PUT.
edit: Here is a quote from Fielding, who is the one that created and defined REST:
A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.]
Today's web browsers only handle GETS + POSTS. In Rails, for example, PUTS + DELETES are "faked" through hidden form fields.
Unless your framework has some workaround to "support" PUTS + DELETES, don't worry about them for now.