A framework to:
- declaratively define resources and their relationships
- handle resource serialization/deserialization to arbitrary data storage (e.g.: MySQL, NoSQL, plain files)
- expose HTTP interface
- handle authorization for individual resources
Check documentation for more detailed information.
## Code style
Run [pep8](https://pypi.python.org/pypi/pep8) and [pyflakes](https://pypi.python.org/pypi/pyflakes) in **src** directory
## Version policy
[Semantic version](http://semver.org/)
## Changelog format
```
VERSION RELEASE-TIMESTAMP=YYYY-MM-DD
[Author Name <author@email>]
* CHANGE_TYPE=MAJOR|MINOR|PATCH: change description
```
Example
```
12.11.3 2014-01-12
[John Smith <john.smith@example.com>]
* PATCH: refactored the modules
* MINOR: added a new class
* MAJOR: removed deprecated function
```
Notes:
- It is a good idea to annotate each commit with "1:", "2:" and "3:" message for PATCH|MINOR|MAJOR respectively so that
it is easier to control the version based on the output of `git log` command
- There is no need to modify changelog when documentation or travis related files are updated. Only changes of the
source code are important.
## Release steps
1. Switch to **dev**
2. Make sure that pep8 & pyflakes checks and tests pass
3. Increment the version in **CHANGES** file according to the types of changes made since the latest release. Add
timestamp to indicate when the version was released.
4. Commit the changes
5. Switch to **master**
6. Merge **dev** into **master**
7. Execute `git tag VERSION -m VERSION`
8. Push **dev** & **master** branches to upstream
9. Push tags to upstream
## Pull requests
Always create your own feature branches from the **dev** branch. Not from **master** one.
1. Make sure that all commits have descriptive messages and are up to the point
2. pep8 and pyflakes checks are supposed to pass
3. All tests are supposed to pass
4. If it is a new feature - make sure that new tests are created and they pass
5. Add a new set of bullet points to the latest changelog entry according to the specified format
6. Create a pull request against the **dev** branch
## Links
- Travis CI: https://travis-ci.org/F-Secure/resource-api
- Read the docs: http://resource-api.readthedocs.org/en/latest/
## Note
The core part of the project development work was done within the Digile’s Data to Intelligence
program http://www.datatointelligence.fi/ and supported by Tekes, the Finnish Funding Agency for Innovation.
Metadata
Release files for resource-api-http 3.1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| resource-api-http-3.1.1.tar.gz | 8.4 kB | Without provenance | Details |
Release files / resource-api-http-3.1.1.tar.gz
| Download URL | resource-api-http-3.1.1.tar.gz |
|---|---|
| Size | 8.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
3a53a3c310b1503bbe5e78d3d8d3aaa679a3b051dbf3d054de31ed8476c1c646
|
|
BLAKE2b-256 checksum How to use checksums |
a835f84ad9a9e7865c5ab7f484cce53ba16a4c82d7e961820ebb33a978aa8595
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for resource-api-http 3.1.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.