daniel
February 4, 2017, 10:01pm
1
According Structured Data docs, new SDs are created with PUT and updates are made with POST:
safe_core calls PUT to store a new structured data on the SAFE Network and POST to update an existing structured data. When a structured data is created for the first time, the app should call the PUT endpoint and when updating an existing structured data, the app should call the POST endpoint.
Is this right? In a RESTful way, it should be the inverse (POST = create, PUT = update).
1 Like
daniel
February 4, 2017, 10:08pm
2
Or maybe I’m just ignorant about it
Just did some research and it seems that some people prefer to use PUT to create and POST to update. Rails, Laravel, Wordpress and many other frameworks enforce the PUT=update / POST=create idea. Maybe it’s a CRUD thing, so I thought the API was wrong.
2 Likes
digipl
February 5, 2017, 3:02pm
3
Structured data will be replaced by Mutable data. Better read the RFC about it.
# MutableData
- Status: proposed
- Type: feature
- Related components: `safe_core`, `safe_launcher`, `safe_vault`, `routing`
- Start Date: 09-November-2016
- Discussion:
## Summary
Combining `StructuredData` and `AppendableData` into a new single data type, `MutableData`, similar to HashMap.
## Conventions
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119).
## Motivation
Existing data types don't support granular access control which is required for mobile platforms where access to the network through an intermediary like SAFE Launcher is complicated: each app would have to receive full permissions to modify and fetch data on a user's behalf and private keys to sign it. This compromises security and allows malicious apps to get full access to the user's data.
To mitigate that, `MutableData` provides fine-grained access control and more narrow-scoped data operations. This data type is an evolved version of `AppendableData`. It combines `StructuredData` and `AppendableData` features and improves the network efficiency, saves bandwidth, and provides a standardised approach for apps to fetch and mutate data in the network.
## Detailed design
The proposed data type defines discrete actions on data that doesn't require a user to replace or fetch the entire structure contents. This is enabled by functionality similar to this of the HashMap data structure or a key-value database such as [Redis](http://redis.io).
This file has been truncated. show original
Other RFC you must read is:
# Authorise apps on behalf of the owner to mutate data
- Status: proposed
- Type: feature
- Related components: `safe_core`, `safe_vault`, `routing`, `safe_launcher`
- Start Date: 10-November-2016
- Discussion: https://placeholder.com
## Summary
Detail how apps route their mutation requests to Data-Managers and how revocation works.
## Conventions
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119).
- When we talk about an owner's Maid-Managers we refer to the address `sha256::hash(owner's-MAID-sign-PublicKey)`.
## Motivation
- If the requests made by the permitted apps need to be charged these must all go through the Maid-Managers and they should know about the owner that an app is associated with so that they can charge the correct account.
## Detailed design
We require all mutations to go via the owner's Maid-Managers. Maid-Managers will keep a list of `sign::PublicKey` which is the representation of the apps the owner has allowed to mutate the network on their behalf. Maid-Managers will then forward the request to the appropriate Data-Managers. The type `MutableData` thus does not need to store any signatures and Data-Managers will use the group authority to trust the requester of the mutation. Then they will use the `permissions` field to allow or disallow the mutation itself.
This file has been truncated. show original
and
# Authentication Protocol
## Summary
This appendix of the New App Authentication flow describes the protocol between the Authenticator and third party apps to gain and extend access.
## Basics
In order to provide the same user flow and behaviour on mobile and desktop platforms, this protocol is using url-open commands to communicate between the apps. The Authenticator, when starting up, must register itself as the default handler for the `safeauth`-scheme on the system it was started on. Similarly, every app that wants to communicate with Authenticator must register itself under `safeauth-${base64(appId)}` - we will refer to this as the appURI from here on.
All keys handed over with the protocol, let that be the app authentication keys, dataIds to containers or encryption keys of any kind, are sensitive information that will persist unless explicitly changed by the User. It is the receiving apps responsibility to savely store and retrieve them. If the app isn't sure it can do this, it should ask for permissions on every start and only keep those in memory. When the authenticator is asked to grant the exact same permissions is has granted that app before, it should respond with the necessary information without any further user interaction.
**TODO**: base64 contains '=' as fillers character, and we are using `-` for prefixing: Are those allowed in url-schemes on all platforms? If not we might have to remove them before creating our return URLS.
## Format
The protocol is based on strings of valid URIs with a colon (`:`) delimiters, encoding JSON data within base64 packets as follows:
This file has been truncated. show original
2 Likes
mav
February 8, 2017, 2:31am
4
My understanding of REST is
PUT /thing/:new_id
to create
PUT /thing/:existing_id
to update
POST /things
to create
POST /thing/:existing_id
to update
PATCH /thing/:id
to update part of the resource
More info When to use PUT or POST and When to use the PATCH method . As far as I can tell, there’s no exact ‘standard’ .
On the topic of the safe network API methods, as @digipl says there are changes coming to the way it works. I have also been frustrated by the inconsistency between PUT and POST as implement by safe but I’m confident it will be simplified before being set in stone
as @ben explains at the start of January regarding the API :
we is a very verbose and not clearly defined API and requires a lot of very similar terms in your head, which can make it very confusing. Which is why we are intending of replacing this with a much cleaner approach
4 Likes