What RFC's are good to know as a web-developer?
RFC 2616 about HTTP would be relevant, but I am not really sure RFCs are the best way to learn about web applications. Some RFCs are long, very detailed and not really useful as a general introduction IMO.
Related
If the question doesn't belong on stackoverflow, sorry for the noise. I couldn't find a better suiting site within stackexchange.
Question
There are definitions of:
Selective Forwarding Middlebox (abbreviated SFM) defined in RFC 7667 Section 3.7
Selective Forwarding Unit (abbreviated SFU) defined in WebRTC Glossary
What is the difference of these things? Are they essentially the same?
They are the same. The usage of SFU in a WebRTC context predates RFC 7667 and is hence a much more commonly used term (ironically the RFC itself still mentions 'SFU' in one place without defining the term).
See also this commit which does a simple replace of SFU with SFM.
We're trying to use RestSharp, as it seems to be the preferred software for REST communications. However, there doesn't seem to be any thorough documentation anywhere. The restsharp.org site has a couple of simple examples, and it refers to the GitHub site (https://github.com/restsharp/RestSharp/wiki) for documentation. That covers a lot more, but still not that much. Otherwise, the RestSharp site just links back to StackOverflow.
Is there a good document that describes RestSharp methods and usage in detail? (I'll probably feel like an idiot when someone points out the obvious, but I'm just not seeing it!)
Thanks!
In most tutorials, documentation, articles etc. about RESTful I come across a few of the same points, but yet I rarely ever see these 'What makes it RESTful' points implemented.
For example, I've read this many times:
Content type
Using HTTP headers
Accept: application/json, text/plain
Extension in the URL
Not RESTful, URLs are not the place for Content-Type
I have never come across an API where I have seen this implemented. Every API I have ever used has always required me to append XML or JSON to the end of the URL. Are they doing it wrong?
Versioning
Version media types
application/vnd.something.v1+json
Custom header
X-API-Version: 1
Version in URL
/v1/resouce
Not RESTful, by putting the version in the URL you create separate resources
If you need to introduce non-backwards-compatible functionality surely creating a seperate resource is the correct thing to do?
Once again, in all versions of APIs I've used, they use v1, v2 in the URL (such as google, imgur etc.)
By not implementing these points, would my API not be considered RESTful?
To clarify these points would be much appreciated.
1) Using accept header or using format specific URLs are both valid in a RESTful system. The article you are citing is wrong.
2) Saying v1/resource is not RESTful is also incorrect. You cannot look at a URI and make a conclusion about its RESTfulness. Adding a v1 at the root of your URL is probably not a great thing to do if you are trying to incremental evolve your system. In effect it declares a whole new URL space and obsoletes the old one. That's pretty drastic. RESTFul systems try and enable incremental and evolutionary change to a system. So doing /resource/v2 is actually much more compatible with that goal.
The unfortunate phenomena at work here is that many developers who are learning about REST discover that the vast majority of systems out there that claim to be doing REST are not actually conforming to the constraints of REST. So they quickly develop a zeal for telling everyone what is and is not RESTful. Many of these people have not yet fully understood the constraints and end up making up new ones that don't exist. The "RESTFul URL" fallacy is a classic. "POST must create a resource" is another common one.
My guidance to anyone learning REST is, if someone tells you that something is not RESTful, you ask them what constraint it is violating and what is the practical impact of ignoring that constraint. If they can't answer that, then politely ignore them.
The true definition of REST is obviously in the doctoral dissertation written by Roy Fielding in 2002. Do all of the API's out there that call themselves RESTful follow the guidelines specified by Fielding? The answer is no. The definition of REST has been watered down by some to just mean anything that does not use SOAP. I would worry less about what is RESTful and more about what is good practices. It is a good practice to specify the content type in the header of the request. It is also a good practice to version your API's. A good resource for information on API best practices is from the guys at Apigee as they have a lot of experience in this area. Check out their webinar on RESTful API Design where they ask if you are a pragmatist or a RESTafarian.
I'm working with WCF at the moment and attempting to implement a custom security model based around an API key and signature (similar to how Facebook/Flickr/OAuth etc. work).
There are a while bunch of classes like ServiceAuthorizationManager, SecurityToken, SecurityTokenValidator, IAuthorizationPolicy and so on, but I can't seem to find any documentation about how these work together or what the conceptual security model is for WCF.
I'm really looking for something that details how these classes fit and work together, so I can understand where to extract credentials, where to validate they are correct, where to decide what level of access to give them and so on. If there is a book I can buy about this stuff it would be even better, as all the WCF books I have found skip over all this stuff entirely.
Is there any documentation out there?
Take a look at Juval Lowy's excellent "Programming WCF Services," 2nd Edition:
Here's the link to Amazon's page on it.
Chapter 10 is completely devoted to security.
Microsoft has released a WCF Security Guide - a free(!) eBook. You can find it here.
That's an awful lot of information to wade through. Good luck!
I'm starting to work with my model almost exclusively in WCF and wanted to get some practical approaches to versioning these services over time. Can anyone point me in the right direction?
There is a good writeup on Craig McMurtry's WebLog. Its from 2006, but most of it is still relevant.
As well as a decision tree to walk through the choices, he shows how to implement those changes using Windows Communication Foundation
See "Versioning WCF Services: Part I" and "Versioning WCF Services: Part II".
See also:
WCF Backwards Compatibility and Versioning Strategies – Part 1
WCF Backward Compatibility and Versioning Strategies – Part 2
WCF Backward Compatibility and Versioning Strategies – Part 3
While not an instant answer for you, I found the book Learning WCF very useful; in it there's a small section on versioning (which is similar to Craig McMurtry's advice posted by Espo). If you're looking for a general intro book, it's very good. Her website has lots of good stuff too: Das Blonde
Edit:
No sure why her site isn't responding; it's been a while since I've visited, so maybe she shut it down. No sure.