According to the filepicker web docs, filepicker.pick will no longer return key as an attribute of the FPFiles passed to the onSuccess callback.
Since filepicker.pick seems like the most general-case api call, it seems like it would be representational of how other api calls might be changing going forward.
This makes me wonder if the FPFiles passed to the onSuccess callback in filepicker.makeDropPane will also no longer be getting a key attribute. The documentation makes no note about it in the filepicker.makeDropPane area.
There is also nothing in the docs that says whether backing up your images to S3 is an option that you can specify when using filepicker.makeDropPane. I actually do want this to happen, and it's working fine, but I'm not specifying any boolean parameter that says filepicker should do this for me. This makes me worry that at some point filepicker may change the default behavior under the hood, breaking my application without warning.
The documentation for filepicker.pick states:
Note: the "key" parameter is deprecated and will be removed soon. If
you want to store files immediately after picking, use the
filepicker.pickAndStore call.
Well, that's good to know about filepicker.pick, but what about filepicker.makeDropPane? Is there a planned filepicker.makeDropPaneAndStore? Will there be some other way to specify automatic upload to S3? Will filepicker.makeDropPane forever upload to S3 automatically, for no specified reason? Or should we treat filepicker.makeDropPane like filepicker.pick, and assume it doesn't upload to S3, and call filepicker.pickAndStore for each FPFile after they're uploaded? If so, when should we make that change, because right now it'd be redundant since it's already uploading to S3 automatically, and we'd be duplicating each S3 upload?
In addition to these questions, currently the FPFiles being passed to the onSuccess callback of filepicker.makeDropPane have an undocumented id attribute. This id attribute isn't unique - it's the same for every FPFile. Will this change to being unique? Should we avoid using this? Why's it there if it's not documented?
Which FPFile attribute should we use for actually keeping track of FPFiles locally? url?
You're correct in interpreting that the makeDropPane needs a more explicit declaration of where to store the uploads - to "future-proof" your implementation, I'd recommend adding a {store_location: "S3"} as an option, which will signal to us that the upload should be stored into your S3 (as opposed to rackspace, etc.), and will guaranteeing that we return a key.
Regarding the id attribute, I'm not seeing this behavior, if you have any more specifics (or a jsfiddle, etc) that would be helpful.
Related
I have a PWA and in the sw.js file, the cache name is set like:
var cacheName = 'my-super-sweet-pwa-app8wfjawa89ja0';
The my-super-sweet-pwa part can change though, so sometimes, in the current state, it's possible that the cache name could change, including after the PWA already is installed.
I am a bit confused as to how the cache actually functions. How would this affect things?
Each Cache instance in the Cache Storage API has a specific name. When you open a cache to perform a read or write operation, you need to specify the same name as you previously provided if you want access to the previously cached data.
If you open a cache using a brand new name that had never been used before, the cache will be empty, and you won't be able to match() anything in it. You can still write new Responses to an empty cache.
There's a helper method, caches.match(), that will find a given Request in any cache, regardless of the cache name.
So that's the significance of cache names. But taking a step back, it sounds like you might have more fundamental questions about how to effectively use caches and how they come into play with the service worker lifecycle. I would recommend reading through The Service Worker Lifecycle before you do anything else, as that will explain how these concepts relate to real-world scenarios.
I read posts and did research on rest call. However I cant figure out this particular situation.
I don't know if I should be using Get or Post.
I have a service call that update the database (unlocking a record, changing a flag to false). It's changing the data in database, however no matter how many times you call this service, the change will only happen once, even if you unlock the record three times, the state will still be unlock, so Idempotent.
So that means I can use Get for this instead of post? but can I use Get when I am updating data in the database?
The service call also only take in one Id, I want to add it to the query parameter instead of the body, it would be weird to use post without body right?
All GET requests should be safe. This means that doing a GET request should have no consequences to the state of your database.
Usually when a resource is changed, PUT is used. POST is also ok. It doesn't matter that POST is not guaranteed to be idempotent. If it does in some cases (like yours) it doesn't break the spec.
However, it sounds like in your case PUT is more appropriate.
I have an app that makes extensive use of the Editor Framework. Right now I'm at the point where I want to add a new feature: if a user edits an entity, I'd like to record which changes were made and store them in a separate datastore entity. This requires knowing if a field was changed, the field name, and the value it was changed to.
This is what I'd like to implement:
App calls edit(bean);
User makes changes, calls flush() and data gets sent back to server.
In server handler, changes from the bean are sent to processChanges(List<String> paths) which then creates and stores the record that "field foo" was changed to "bar", and so on.
The entity is saved, overwriting the existing one.
I use GWTP and currently use the RPC Command Pattern. I've read a bit about RequestFactory and as I understand, one of its main benefits is that it only sends the changed fields known as "deltas" back to the server to minimise the payload, so I'm wondering if using RequestFactory would be a better fit for my app?
Apologies - I've been reading through the GWT docs and Javadocs for the Editor Framework and RequestFactory but I'm still pretty confused. RequestFactoryEditorDriver.getPaths() seems like it might be what I need but any advice or pointers greatly appreciated.
I could probably watch for changes client-side but that seems like a bad idea.
I believe you could do that using an EditorVisitor, similar to the DirtCollector visitor used internally by the Editor framework (have a look at the PathCollector for how to collect paths in a visitor).
I would start by visiting the hierarchy to collect the initial values just after the call to edit() (this is done already by the DirtCollector internally, but there's no way to access its results, and it only collects leaf values anyway).
Then you could call flush() ans see whether there are errors, and possibly validated your object to see if everything's OK. Then you visit the hierarchy again to collect the changes (against the initial values you previously collected) so you can send them to the server.
We are planning to use GET for all retrievals and DELETE for all delete operations.
HTTP PUT , POST and PATCH is confusing. After a lot of reading, this is my understanding. Please correct if I am wrong.
POST - Not Idempotent ; so can be used for creating new resources/subordinate resource. Each time it creates a new one the ID gets changed and so it is best suited.
PUT - Idempotent; cannot be used for create since the second time the same request comes, it creates a new resource again with different ID.
Can be used for update but all attributes should be passed each time it is updated. To achieve this, a GET should be done prior to update operation. Overhead.
Why not use POST for updates too?
PATCH -Not sure if it is suitable for JAX-RS 1.1.
Thanks in advance.
I think your question is this:
Why not use POST for updates too?
The benefit of having POST and PUT make different types of changes to the resource you're allowing an extra vector of the request to modify the action without having to add more URLs. That way, URLs can stay short, clean, and reflective of what it is the represent.
However, to clear things up PATCH is often used for partial updates. So, like PUT it is idempotent, but will only modify the parts of the resource which you send in the request body whereas PUT is expected to modify the whole thing. This is often overlooked in REST. You can read more on the Rest Cookbook website.
Apart from that, from what I can tell your understanding is very good. Enjoy RESTing!
I'm trying to build a RESTful webapp wherein I utilize GET, POST, PUT, and DELETE. But I had a question about the use of DELETE in this particular app.
A bit of background first:
My webapp manages generic entities that are also managed (and, it happens, always created) in another system. So within my webapp, each entity will be stored in the database with a unique key. But the way we will be accessing them through URLs is with the unique key of the other system.
A simple example will make this clear, I think. Take the URL /entity/1. This will display information for the entity with ID 1 in the other system, and not my own system. In fact, IDs in my system will be completely hidden. There will be no URL scheme for accessing the entity with ID of 1 in my own system.
Alright, so now that we know how my webapp is structured, let's return to deleting those entities.
There will be a way to 'delete' entities in my system, but I put quotes around it because it won't actually be deleting them from the database. Rather, it will flag them with a property that prevents it from appearing when you go to /entity/1.
Because of this, I feel like I should be using PUT ('deleting' in this way will be idempotent), since I am, from the perspective of the data, simply setting a property.
So, the question: does the RESTful approach have fidelity to the data (in which case it is clear that I am PUTing), or the representation of the data in the app (in which case it seems that I am DELETEing)?
You should use DELETE.
What you intend to do with your data is called "soft deleting": you set a flag and avoid flagged items from appearing. This is internal to your webapp and the user doesn't have to know that you're soft deleting instead of deleting or whatever you want to do. This is why you should use the DELETE verb.
I think there is no definitive answer. I'd rely on whether 1. the soft-delete, recover and destroy actions are an actual feature of your api OR 2. soft-delete is merely a "paranoid" database engineering pattern.
The "soft" deletion is transparent for the api client, in which case using the DELETE verb seems like the way to go
Everything is as if the item was to be removed once and for all, but engineers want to keep it somewhere in the database
Api clients have the ability to recover or destroy the soft deleted resource, in which case soft deletion and recovery can use POST on a different action url like /resource/:id/softdelete and the destroy action would be the one using DELETE.
Another way to go may be to use DELETE with no query parameter to soft delete, and add ?destroy=true to actually destroy. But this approach seems less explicit and more prone to errors.
The DELETE method has very specific semantics in HTTP, which must not be overloaded
or stretched by a REST API’s design. Specifically, an API should not distort the intended
meaning of DELETE by mapping it to a lesser action that leaves the resource, and its URI,
available to clients. For example, if an API wishes to provide a “soft” delete or some
other state-changing interaction, it should employ a special controller resource and
direct its clients to use POST instead of DELETE to interact.
Source: Rest-API Desgin Rule book by Mark Massé
Suggestion:
POST: /entity/1/your-soft-delete-controller-name