After reading some articles, I realize that using localStorage and sessionStorage is a bad idea for storing JWT tokens, and cookies with httpOnly should be used instead.
As I read more and learn some about indexedDB today, I wonder if indexedDB is a secure option for storing JWT tokens as well?
The short answer is NO, as you are pretty much convinced using localStorage and sessionStorage is a bad idea. IndexedDB is also vulnerable to cross-site scripting (XSS) attacks similar to local storage.
Regardless of security -
IndexedDB API is powerful but may seem too complicated (I'd go so far as to say 'horrific') for simple use cases such as storing jwt token. Because, even for this implementation, you will have to write more code. (More code, which means maybe more bugs). Just be aware of the steep learning curve when you're getting started with it.
IndexDB is not actually designed for such use cases. It is designed to work with significantly larger amounts of structured data. For basic key-value operations, IndexedDB performance takes a hit.
Browser support for IndexedDB isn't also quite good.
Related
Is making a shopping cart using IndexedDB a good idea rather then the implementation of Sessions and cookies if we support only modern browsers?what difference it can make in comparison with session and cookies?(skipping compatibility issue)
Use indexedDB if you need scalability over localStorage, sessionStorage, or cookies. Otherwise there is not much point, as indexedDB is more complicated and slower.
may I have some example/typical use case of HATEOAS? I agree it can be a very powerful concept provide great flexibility but I am not sure how to properly get benefit from HATEOAS. would be great if you can share your experience/use case.
A good answer from #dreamer above, but HATEOAS is not present in most REST-based services. It is a constraint on the REST architecture style that allows clients to interact with a service entirely via the hypermedia contained in the resources.
If you look at the Twitter or Facebook REST APIs, you won't find hypermedia. Look at the Facebook friendlist resource. There are no hypertext links in that resource that you can use to transition the state of the resource - to delete, update, etc. Instead, you need to read the out-of-band documentation to understand what you need to do to delete that resource.
One of the claimed advantages of using hypermedia in your APIs is that you can manage change within the resources themselves. For example, what if Facebook wanted to add additional functionality to the frendlist? If it were built with HATEOAS in mind, the resource would be updated to add the hyperlinks provides those additional state transitions.
If this sounds difficult, you're right. But as a developer of client applications, however, once you understand how the hypermedia is presented, you can build applications that will evolve along with the API itself.
So how do you build APIs using HATEOAS? A number of options are out there, but I like the Hypertext Application Language (HAL) the best.
UPDATE: Since you asked for an example, here's a link to a demo using HAL.
Good public HATEOAS use cases are hard to find, because there are a lot of misconceptions around REST, and HATEOAS can be hard to implement. You really need to have a good understanding of its benefits, before you're willing to put yourself through the trouble of getting it to work, and if the clients don't follow it correctly, all work will be in vain.
From my experience, implementing proper REST in a company is a culture change as important as moving to version control systems or agile development. Unless everyone adopts it and understands it, it causes more trouble than it solves.
Having that in mind, I think the best example one will find is the foxycart.com HAL API, on the link below:
https://api-sandbox.foxycart.com/hal-browser/hal_browser.html#/
It's very powerful concept used in RESTful presentation of the application to the client. There are many many projects which are adopting this interface now. A typical use case for this is Web Services APIs using RESTful APIs. A RESTful APIs typically consists of the following elements:
base URI, such as http://example.com/resources/
an Internet media type for the data. This is often JSON but can be any other valid Internet media type (e.g. XML, Atom, microformats, images, etc.)
standard HTTP methods (e.g., GET, PUT, POST, or DELETE)
hypertext links to reference state
hypertext links to reference related resources
The application state can be modified using above HTTP methods for example, to get a particular resource, A client can issue a REST query using curl like:
curl -X GET --url "http://example.com/resource/" -X "Content-Type:application/json"
you could go through the man pages for curl and its usage. More on RESTful interface concepts can be looked upon at wiki
SO I am about to write a REST API with Django using django-piston but my employer just wanted to be able to retrieve and create data, so I was wondering what is the difference between:
just creating methods to set and retrieve data and making them
publicly available (of course with authentication and validation in
place)
creating a REST API for the purpose of creating and retrieving data
?
Thanks in advance!
Your second point is basically a sub set of your first point. REST is just a set of methods to create and retrieve data. It is however a fairly standardized set of methods using HTTP verbs instead of different urls to declare what you are trying to do.
So instead of /comments/new/, /comments/delete/, /comments/update/, you would just have /comments/ and POSTing to create, PUTing to update, and DELETEing to delete.
I also agree with Zach on TastyPie for what it's worth.
The two key alternatives to "RESTful" would be traditional html forms or a more formal RPC protocol thats implemented on top of HTTP, like XML-RPC or SOAP.
The main advantage of the former is that it can be invoked through a web-browser with no client code at all; but unless the application is designed in a thoughtful way, it's often quite difficult to drive such an interface from a custom client; which must often set cookies to do authentication and specify arguments that it isn't interested in. There's no notion of data types for this kind of API either, everything is text.
The latter has the advantage of getting you up and running in no time at all; You can just write normal functions in python, with a decorator, and they are available for clients that have the appropriate client libraries. The main disadvantage is also that this usually requires the client have such a library. Things like soap or xml-rpc are not typically an option for in-browser applications, or on resource-constrained devices.
RESTful is a sort of middle way that combines many advantages of both. Since the semantics are defined purely in terms of HTTP, any client capable of issuing HTTP can use a RESTful API. HTTP is much more flexible than plain old web forms, usually in terms of giving a Content-Type to the request or response that supports the needed structure. Unfortunately, there's not really a single standard defining how RESTful clients or services should represent their data, so there's necessarily a bit of customization on both ends to get things to work in the best way. Sometimes the flexibility means that you spend more time getting the api just right then you would have had to if you used a different interface, but it often leads to a thinner and yet less leaky abstraction.
There are a few standards or de-facto standards that are also good models of RESTful interfaces, such as json-rpc and the Atom Publishing Protocol.
I just finished reading Restful Web Services and Nobody Understands REST or HTTP and am trying to design an API with a RESTful design.
I've noticed a few patterns in API URI design:
http://api.example.com/users
http://example.com/api/users
http://example.com/users
Assume that these designs properly use Accept and Content-type headers for content negotiations between XHTML, JSON, or any format.
Are these URI's a matter of a pure RESTful implementation vs implicit content negotiation?
My thoughts are that by explicitly using API in the URI is so that a client will expect a data format that is not inherently human pleasing hypermedia and can be more easily consumed without explicitly setting an Accept header. In other words, the API is implying that you expect JSON or XML rather than XHTML.
Is this a matter of separating resource representations
logically on the server side?
The only justification I can come up with for why someone would design their URI's with an API subdomain is because, based off my assumption that this is a scaling technique, it should make routing request load easier in a multi-tiered server infrastructure. Maybe situations exist where reverse proxies are stripping the headers? I don't know. Different servers handling different representations?
Maybe a subdomain is used for external consumers only so that the server avoids the overhead from internal usage. Rate limiting?
Am I missing a point?
My proposed design would attempt to follow RESTful practices by setting appropriate headers, using HTTP verbs appropriately and representing resources in a fashion that I feel including 'API' in the URI would be redundant.
Why would someone design a RESTful API with 'API' in the URI?
Or could they? Maybe my problem with not understanding this design is that it doesn't matter as long as it follows some combination of specification which may not lead to a RESTful API implementation but close? There is more than one way to skin a keyboard cat.
HATEOAS related?
Update: While researching this topic I have come to the conclusion that it's important to consider ideas from REST but not to treat it as a religion. Thus, whether or not to have 'api' in the URI is more of a design decision than a steadfast rule. If you plan to expose your website's API publicly it would be a good idea to use an api subdomain to help deal with the application's logic. I hope that someone will contribute their insight for others to learn from.
I would (and have) done it to separate it from the 'website' infrastructure because it's probably going to have a higher load and require more infrastructure - it's a lot easier to do millions of API calls a day than get that in page views because you have the full load of n sites/companies and their efforts and traction, collectively and even in some cases individually they're going to attract more traffic than you yourself.
This is my understanding and point of view about your question :
Are these URI's a matter of a pure RESTful implementation vs implicit
content negotiation?
No, they are not part of any official documentation (that I know of), and are usually at the developper/team standards discretion. For example, Zend Framework uses some utility classes to detect XHR requests and how responses should be returned. Granted, ZF is not pure RESTful design (or most PHP application as a matter of fact), but it is still possible to write such designs even in PHP.
I have often seen api being used in urls when the returned data expected is indeed not meant to be used as is for display to the end user. However it is usually a design decision and not necessarily an implied standard.
Is this a matter of separating resource representations logically on
the server side?
More or less. For example, when performing a PUT request, for example, the interface does not necessarily need to be entirely refreshed, and often a simple response message is good enough. While this response message is part of the view, it is not the view. So, for example, http://domay.com/users/ would return the interface to manage users (or whatever), http://domain.com/users/api would perform operations and return interface updates (without a page reload).
Am I missing a point?
Weell, no. Since it is a design decision to use or not api in the URL, you're not missing anything here. With the proper headers,
http://domain.com/users/api/get
http://domain.com/users/get
http://domain.com/users/
can all be valid RESTful requests.
Why would someone design a RESTful API with 'API' in the URI?
Simply put, to have an URL naming convention. So that, when looking at a request in logs, documentation, etc. One will understand it's purpose.
Also keep in mind, that most frameworks (django, RoR,...) provide URL-based routing out of the box. You probably need different views for API vs. HTML responses to manage things like authentication, trotting, limits-check and other specific stuff differently.
Putting in place an additional HTTP-Header based routing system to allow, as you say, implicit content negotiation is often not worth the effort.
User-visible webpage URLs are subject to the whims of webmasters, designers, corporate organization, marketing, fashion, technology, etc.
An API, on the other hand, is supposed to remain stable. By using a subdomain you isolate your API from the rest of the website and the changes it is likely to undergo in time.
Ok so I've implemented both REST and SOAP services and I like both depending on the context. For me, WS* is great when I want an explicit contract between the server and the client e.g. for sensitive information or for mission critical stuff. REST on the other hand whilst flexible in terms of the schema definition, is in my mind more ideal for content services or data which is not required to undergo any serious business logic.
REST seems to be very much the flavour of the day, and I was somewhat put out when Martin Fowler et al from Thoughworks gave this podcast: http://www.thoughtworks.com/what-we-say/podcasts.html on REST and were derisive toward WS*. Whilst the man himself is well respected, am I right in thinking that there still is very much a place for SOAP and pinch of salt is required here? And has anyone used REST in a serious business application?
Can you document your REST api by providing someone a description of the media types you use and a single URL?
If you find yourself providing a list of URLs and what verbs can be used on those URLs then you probably don't have a REST api.
Once you have created a true REST api then go back and compare it to WS* api. You will see they are very different.
REST apis can easily handle "serious business logic" and yes I have used REST in a serious business application.
Diary of a Fence Sitting SOA Geek - Dr Mark Little
Presentation is very recent - pretty revealing stuff.
REST actually works. It's not as good for repeat business as SOAP is. So many consultants fight to save SOAP on that basis. As the tools and frameworks for RESTful architectures improve, businesses will move in that direction. Governance is big talk at the moment also.
The new version of JAX-RS is a pretty interesting new tool for RESTful dev, Mark Little mentions this in his presentation.
You're probably better off considering SOAP as legacy technology, it'll serve you better going forward. ;)