create, read, update, delete

39 results back to index


pages: 153 words: 27,424

REST API Design Rulebook by Mark Masse

anti-pattern, business logic, conceptual framework, create, read, update, delete, data acquisition, database schema, hypertext link, information retrieval, off-the-grid, web application

Controller resources are like executable functions, with parameters and return values; inputs and outputs. Like a traditional web application’s use of HTML forms, a REST API relies on controller resources to perform application-specific actions that cannot be logically mapped to one of the standard methods (create, retrieve, update, and delete, also known as CRUD). Controller names typically appear as the last segment in a URI path, with no child resources to follow them in the hierarchy. The example below shows a controller resource that allows a client to resend an alert to a user: POST /alerts/245743/resend URI Path Design Each URI path segment, separated by forward slashes (/), represents a design opportunity.

Vocabulary review TermDescription Authority A URI component that identifies the party with jurisdiction over the namespace defined by the remainder of the URI. Collection A resource archetype used to model a server-managed directory of resources. Controller A resource archetype used to model a procedural concept. CRUD An acronym that stands for the four classic storage-oriented functions: create, retrieve, update, and delete. Developer portal A Web-based graphical user interface that helps a REST API acquire new clients. Docroot A resource that is the hierarchical ancestor of all other resources within a REST API’s model. This resource’s URI should be the REST API’s advertised entry point. Document A resource archetype used to model a singular concept.

For example, this API interaction design is preferred: DELETE /users/1234 The following anti-patterns exemplify what not to do: GET /deleteUser?id=1234 GET /deleteUser/1234 DELETE /deleteUser/1234 POST /users/1234/delete * * * [20] Web Resource Modeling Language (WRML) was introduced in WRML [21] http://tools.ietf.org/html/draft-gregorio-uritemplate. [22] CRUD is an acronym that stands for create, read, update, delete—the four standard, storage-oriented functions. URI Query Design This section provides rules relating to the design of URI queries. Recall from RFC 3986 that a URI’s optional query comes after the path and before the optional fragment: URI = scheme "://" authority "/" path [ "?"


pages: 39 words: 10,453

Designing Great Web APIs: Creating Business Value Through Developer Experience by James Higginbotham

business logic, business process, cloud computing, create, read, update, delete, Internet of things, software as a service, web application

We have four core HTTP verbs that we will focus on, though a few others exist when you need them for uncommon situations. Your API model will provide insight into the lifecycle requirements of your resources. Review your model and notice the verbs you used for each resource. Some resources may require all verbs in our lifecycle: search, create, read, update, and delete. However, other resources may not require update or delete actions. Other resources may be read-only. Therefore, the requirements identified during the modeling phase will inform your API design. As you model your API, you will notice a common pattern between the verbs you choose and the eventual resource lifecycle they require.


pages: 133 words: 42,254

Big Data Analytics: Turning Big Data Into Big Money by Frank J. Ohlhorst

algorithmic trading, bioinformatics, business intelligence, business logic, business process, call centre, cloud computing, create, read, update, delete, data acquisition, data science, DevOps, extractivism, fault tolerance, information security, Large Hadron Collider, linked data, machine readable, natural language processing, Network effects, pattern recognition, performance metric, personalized medicine, RFID, sentiment analysis, six sigma, smart meter, statistical model, supply-chain management, warehouse automation, Watson beat the top human players on Jeopardy!, web application

This means creating a built-in stack that integrates with Big Data databases from the NoSQL world and creating MapReduce frameworks such as Hadoop and distributed processing. Development should account for the existing transaction-processing and event-processing semantics that come with the handling of the real-time analytics that fit into the Big Data world. Creating Big Data applications is very different from writing a typical “CRUD application” (create, retrieve, update, delete) for a centralized relational database. The primary difference is with the design of the data domain model, as well as the API and Query semantics that will be used to access and process that data. Mapping is an effective approach in Big Data, hence the success of MapReduce, in which there is an impedance mismatch between different data models and sources.

See Business intelligence (BI) Big Data and Big Data analytics analysis categories application platforms best practices business case development challenges classifications components defined evolution of examples of 4Vs of goal setting introduction investment in path to phases of potential of privacy issues processing role of security (See Security) sources of storage team development technologies (See Technologies) value of visualizations Big Science BigSheets Bigtable Bioinformatics Biomedical industry Blekko Business analytics (BA) Business case best practices data collection and storage options elements of introduction Business intelligence (BI) as Big Data analytics foundation Big Data analytics team incorporation Big Data impact defined extract, transform, and load (ETL) information technology and in-memory processing limitations of marketing campaigns risk analysis storage capacity issues unstructured data visualizations Business leads Business logic Business objectives Business rules C Capacity of storage systems Cassandra Census data CERN Citi Classification of data Cleaning Click-stream data Cloud computing Cloudera Combs, Nick Commodity hardware Common Crawl Corpus Communication Competition Compliance Computer security officers (CSOs) Consulting firms Core capabilities, data analytics team Costs Counterintelligence mind-set CRUD (create, retrieve, update, delete) applications Cryptographic keys Culture, corporate Customer needs Cutting, Doug D Data defined growth in volume of value of See also Big Data and Big Data analytics Data analysis categories challenges complexity of as critical skill for team members data accuracy evolution of importance of process technologies Database design Data classification Data discovery Data extraction Data integration technologies value creation Data interpretation Data manipulation Data migration Data mining components as critical skill for team members defined examples methods technologies Data modeling Data protection.


Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services by Robert Daigneau

Amazon Web Services, business intelligence, business logic, business process, continuous integration, create, read, update, delete, en.wikipedia.org, fault tolerance, loose coupling, machine readable, MITM: man-in-the-middle, MVC pattern, OSI model, pull request, RFC: Request For Comment, Ruby on Rails, software as a service, web application

When they are received at the web server, a service framework or custom code uses the content found in the message to determine what procedure should be invoked. While this loosens the dependencies between messages and remote procedures, other factors should be considered. Many web services use messages to form their own domain-specific API. These messages incorporate common logical commands like Create, Read (i.e., Get), Update, or Delete. This CRUD approach, however, can lead to a proliferation of messages, even in relatively small problem domains. Consider, for example, a set of services that manages company and contact information. In this scenario, the client developer would have to use eight or more distinct messages, one for each combination of a domain entity (i.e., company or contact) and CRUD operation.

This information establishes the criterion that must be met in order to execute methods on the Service Controller. 87 Service Controller 88 Service Controller C HAPTER 4 R EQUEST AND R ESPONSE M ANAGEMENT Request Method Designators are a second type of routing expression used by frameworks that support Resource APIs (38). Given the template shown above, we might determine that distinct handlers should be created to support read, update, and delete operations for a product resource. These handlers could use the same URI template, but we would also need to indicate which server methods (e.g., GET, PUT, DELETE) should trigger each handler. In the current example, a single “Product Controller” might have three handlers named ReadProduct, UpdateProduct, and DeleteProduct that share the same URI template.

Developers often create one controller for each logical resource in the problem domain when designing a Resource API (38). A domain that involves customers, orders, and products might therefore have three controllers. Each controller would typically contain the handlers for CRUD operations (i.e., Create, Read, Update, and Delete) or nonstandard operations (i.e., POST) that should be allowed for the resource. Resource controllers often include handlers that provide access to related resource collections as well. A customer resource controller might therefore have a handler for a collection of orders that would refer to a separate order controller.


Designing Web APIs: Building APIs That Developers Love by Brenda Jin, Saurabh Sahni, Amir Shevat

active measures, Amazon Web Services, augmented reality, Big Tech, blockchain, business logic, business process, cognitive load, continuous integration, create, read, update, delete, exponential backoff, Google Hangouts, if you build it, they will come, Lyft, machine readable, MITM: man-in-the-middle, premature optimization, pull request, Salesforce, Silicon Valley, Snapchat, software as a service, the market place, uber lyft, web application, WebSocket

We look into each of them in the subsections that follow. 9 Representational State Transfer Representational State Transfer (REST) is the most popular choice for API development lately. The REST paradigm is used by provid‐ ers like Google, Stripe, Twitter, and GitHub. REST is all about resources. A resource is an entity that can be identified, named, addressed, or handled on the web. REST APIs expose data as resour‐ ces and use standard HTTP methods to represent Create, Read, Update, and Delete (CRUD) transactions against these resources. For instance, Stripe’s API represents customers, charges, balance, refunds, events, files, and payouts as resources. Here are some general rules REST APIs follow: • Resources are part of URLs, like /users. • For each resource, two URLs are generally implemented: one for the collection, like /users, and one for a specific element, like /users/U123. • Nouns are used instead of verbs for resources.

(XML and other formats might still be supported to make adoption easy for clients that are already working with those formats using similar APIs.) Table 2-1 shows how HTTP methods are typically used in REST APIs, and Examples 2-1 and 2-2 show some example HTTP requests. Table 2-1. CRUD operations, HTTP verbs, and REST conventions Operation Create Read Update Delete HTTP verb URL: /users Create a new user List all users GET PUT or PATCH Batch update users Delete all users DELETE POST URL: /users/U123 Not applicable Retrieve user U123 Update user U123 Delete user U123 Example 2-1. HTTP request to retrieve a charge from the Stripe API GET /v1/charges/ch_CWyutlXs9pZyfD HOST api.stripe.com Authorization: Bearer YNoJ1Yq64iCBhzfL9HNO00fzVrsEjtVl Example 2-2.

Use what you learned in Chapter 2 to fill out the chart in Table 5-1 Scenario 1 | 65 with pros and cons of each pattern. Here, we’ve filled it out for the MyFiles API. Table 5-1. Pros and cons of different API paradigms for the MyFiles API Paradigm Pros REST MyFiles is essentially resource-oriented—the resources are the archived content and metadata. The operations to support are simple Create, Read, Update and Delete (CRUD) operations. RPC Expandable to other actions beyond CRUD. GraphQL Cons Selected? REST would be a long-term commitment to ✓ a resources model for files. If we need to support several actions, REST might not be a great fit. At this time, there are no operations χ outside of CRUD that this API will execute, so there doesn’t appear to be a need to support other actions.


pages: 352 words: 64,282

MongoDB: The Definitive Guide by Kristina Chodorow, Michael Dirolf

create, read, update, delete, Debian, FOSDEM, pattern recognition, Ruby on Rails, web application

When you want to become a power user, this chapter has you covered; in it we’ll discuss the following: • Using database commands to take advantage of advanced features • Working with capped collections, a special type of collection • Leveraging GridFS for storing large files • Taking advantage of MongoDB’s support for server-side JavaScript • Understanding what database references are and when you should consider using them Database Commands In the previous chapters we’ve seen how to create, read, update, and delete documents in MongoDB. In addition to these basic operations, MongoDB supports a wide range of advanced operations that are implemented as commands. Commands implement all of the functionality that doesn’t fit neatly into “create, read, update, delete.” We’ve already seen a couple of commands in the previous chapters; for instance, we used the getLastError command in Chapter 3 to check the number of documents affected by an update: > db.count.update({x : 1}, {$inc : {x : 1}}, false, true) > db.runCommand({getLastError : 1}) { "err" : null, "updatedExisting" : true, "n" : 5, "ok" : true } 93 In this section, we’ll take a closer look at commands to see exactly what they are and how they’re implemented.

Collections can be accessed from the db variable. For example, db.baz returns the baz collection in the current database. Now that we can access a collection in the shell, we can perform almost any database operation. Basic Operations with the Shell We can use the four basic operations, create, read, update, and delete (CRUD), to manipulate and view data in the shell. Create The insert function adds a document to a collection. For example, suppose we want to store a blog post. First, we’ll create a local variable called post that is a JavaScript object representing our document. It will have the keys "title", "content", and "date" (the date that it was published): > post = {"title" : "My Blog Post", ...

Document Outline Copyright Table of Contents Foreword Preface How This Book Is Organized Getting Up to Speed with MongoDB Developing with MongoDB Advanced Usage Administration Developing Applications with MongoDB Appendixes Conventions Used in This Book Using Code Examples Safari� Books Online How to Contact Us Acknowledgments Acknowledgments from Kristina Acknowledgments from Michael �� A Rich Data Model Easy Scaling Tons of Features� �Without Sacrificing Speed Simple Administration But Wait, That�s Not All� �� Documents Collections Schema-Free Naming Subcollections Databases Getting and Starting MongoDB MongoDB Shell Running the Shell A MongoDB Client Basic Operations with the Shell Create Read Update Delete Tips for Using the Shell Inconvenient collection names Data Types Basic Data Types Numbers Dates Arrays Embedded Documents _id and ObjectIds ObjectIds Autogeneration of _id �� Inserting and Saving Documents Batch Insert Inserts: Internals and Implications Removing Documents Remove Speed Updating Documents Document Replacement Using Modifiers Getting started with the "$set" modifier Incrementing and decrementing Array modifiers Positional array modifications Modifier speed Upserts The save Shell Helper Updating Multiple Documents Returning Updated Documents The Fastest Write This Side of Mississippi Safe Operations Catching �Normal� Errors Requests and Connections �� Introduction to find Specifying Which Keys to Return Limitations Query Criteria Query Conditionals OR Queries $not Rules for Conditionals Type-Specific Queries null Regular Expressions Querying Arrays $all $size The $slice operator Querying on Embedded Documents $where Queries Cursors Limits, Skips, and Sorts Comparison order Avoiding Large Skips Paginating results without skip Finding a random document Advanced Query Options Getting Consistent Results Cursor Internals �� Introduction to Indexing Scaling Indexes Indexing Keys in Embedded Documents Indexing for Sorts Uniquely Identifying Indexes Unique Indexes Dropping Duplicates Compound Unique Indexes Using explain and hint Index Administration Changing Indexes Geospatial Indexing Compound Geospatial Indexes The Earth Is Not a 2D Plane �� count distinct group Using a Finalizer Using a Function as a Key MapReduce Example 1: Finding All Keys in a Collection Example 2: Categorizing Web Pages MongoDB and MapReduce The finalize function Keeping output collections MapReduce on a subset of documents Using a scope Getting more output �� Database Commands How Commands Work Command Reference Capped Collections Properties and Use Cases Creating Capped Collections Sorting Au Naturel Tailable Cursors GridFS: Storing Files Getting Started with GridFS: mongofiles Working with GridFS from the MongoDB Drivers Under the Hood Server-Side Scripting db.eval Stored JavaScript Security Database References What Is a DBRef?


pages: 157 words: 35,874

Building Web Applications With Flask by Italo Maia

continuous integration, create, read, update, delete, Debian, en.wikipedia.org, Firefox, full stack developer, minimum viable product, MVC pattern, premature optimization, SQL injection, web application

We overwrite the is_accessible method, so that users without permission will receive a forbidden-access message, and overwrite the index_view for AdminIndexView and ModelView, adding the login_required decorator that will redirect unauthenticated users to the login page. admin_permission verifies that the given identity has the required set of permissions—RoleNeed('admin'), in our case. Tip If you're wondering what a mixin is, try this link http://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful. As our model already has Create, Read, Update, Delete (CRUD) and permission control access, how could we modify our CRUD to show just certain fields, or prevent the addition of other fields? Just like Django Admin, Flask-Admin allows you to change your ModelView behavior through setting class attributes. A few of my personal favorites are these: can_create: This allows the user to create the model using CRUD.

block statementabout / Control structures blueprintsabout / Blueprints 101 example / Blueprints 101 using / Blueprints 101 creating / Blueprints 101 BSON Typesreference link / MongoDB C columnsabout / Concepts connection poolabout / Hands on reference link / Hands on control structuresabout / Control structures if statement / Control structures for statement / Control structures block statement / Control structures extends statement / Control structures include statement / Control structures set statement / Control structures Create, Read, Update, Delete (CRUD)about / Admin like a boss CSRFused, for securing forms / Securing forms with a CSRF token about / Securing forms with a CSRF token custom pagesadding / Custom pages D databasesetting up / Setting up your database database normalizationreference link / Concepts data normalizationabout / Concepts debuggingabout / Debugging, DebugToolbar, and happiness with Flask-DebugToolbar / Debugging, DebugToolbar, and happiness development environmentprerequisites / Prerequisites and tools tools, using / Prerequisites and tools DigitalOceanURL / Placing your code in a server Document-object Mapper (DOM)about / MongoEngine do extensionabout / Extensions E entities, Flask-PrincipalIdentity / Flask-Principal and Flask-Login (aka Batman and Robin) IdentityContext / Flask-Principal and Flask-Login (aka Batman and Robin) Need / Flask-Principal and Flask-Login (aka Batman and Robin) Permission / Flask-Principal and Flask-Login (aka Batman and Robin) extends statementabout / Control structures extensionsabout / Extensions do extension / Extensions with extension / Extensions configuring / How to configure extensions F filtersabout / Filters fixturesabout / Fixtures example / Fixtures integration testing / Extra – integration testing Flaskfeatures / An introduction to Flask and its features overview / An introduction to Flask and its features URL, for license / An introduction to Flask and its features Flask-Adminabout / Admin like a boss example / Admin like a boss Flask-BoilerplateURL / Structuring your projects Flask-DebugToolbarabout / Flask-MongoEngine, Flask-DebugToolbar used, for debugging / Flask-DebugToolbar Flask-Emptyabout / Extensions URL / Extensions, WTForms and you, Structuring your projects Flask-Loginabout / Flask-Principal and Flask-Login (aka Batman and Robin) example / Flask-Principal and Flask-Login (aka Batman and Robin) Flask-MongoEngineabout / Flask-MongoEngine features / Flask-MongoEngine example / Flask-MongoEngine Flask-Principalabout / Flask-Principal and Flask-Login (aka Batman and Robin) URL / Flask-Principal and Flask-Login (aka Batman and Robin) entities / Flask-Principal and Flask-Login (aka Batman and Robin) example / Flask-Principal and Flask-Login (aka Batman and Robin) Flask-Admin / Admin like a boss custom pages, adding / Custom pages Flask-Restlessabout / Flask-Restless example / Flask-Restless Flask-SkeletonURL / Structuring your projects Flask-SQLAlchemyabout / Flask-SQLAlchemy example / Flask-SQLAlchemy Flask-SQLalchemyabout / Fixtures Flask-testingURL / Behavior testing about / Flask-testing LiveServer / LiveServer assertions / Extra assertions JSON handle / JSON handle Flask-WTFabout / Flask-WTF URL / Flask-WTF features / Flask-WTF integrating, with WTForms / Integration with WTForms forms, securing with CSRF / Securing forms with a CSRF token challenges / Challenges foreign keyabout / Concepts formshandling / Handling forms securing, with CSRF / Securing forms with a CSRF token for statementabout / Control structures foundation.zurb frameworkURL / Serving HTML pages fuzzy testingabout / Fixtures G Gherkin languageabout / Behavior testing URL / Behavior testing H Hello World appabout / Hello World creating / Understanding the "Hello World" app HTMLabout / HTML forms for the faint of heart reference link / HTML forms for the faint of heart HTML formsabout / HTML forms for the faint of heart example / HTML forms for the faint of heart HTML pagesserving / Serving HTML pages I if statementabout / Control structures include statementabout / Control structures input fieldreference link / HTML forms for the faint of heart integration testingabout / Extra – integration testing J JavaScriptreference link / MongoDB Jinja2about / What is Jinja2 and how is it coupled with Flask?


Backbone.js Cookbook by Vadim Mirgorod

Airbnb, business logic, create, read, update, delete, en.wikipedia.org, Firefox, Google Chrome, MVC pattern, QR code, rolodex, Ruby on Rails, web application

So, our application should provide additional functionalities to the end user, such as the following: ‰‰ ‰‰ ‰‰ ‰‰ ‰‰ The ability to see a list of buyers and use it when generating an invoice The ability to manage buyers (create, read, update, and delete) The ability to see a list of bank accounts and use it when generating an invoice The ability to manage his/her own bank accounts (create, read, update, and delete) The ability to edit personal details and use them when generating an invoice Of course, we may want to have more functions, but this is enough for demonstrating how to design an application using the MVC pattern. 3.

Let's follow the ensuing steps to design an MVC structure for the Billing Application: 1. Let's write down a list of functional requirements for this application. We assume that the end user may want to be able to do the following: ‰‰ ‰‰ ‰‰ ‰‰ ‰‰ ‰‰ ‰‰ Generate an invoice E-mail the invoice to the buyer Print the invoice See a list of existing invoices Manage invoices (create, read, update, and delete) Update an invoice status (draft, issued, paid, and canceled) View a yearly income graph and other reports 2. To simplify the process of creating multiple invoices, the user may want to manage information about buyers and his personal details in the specific part of the application before he/she creates an invoice.

REST and Storage Architecting the REST API for the backend Representational State Transfer (REST) is an architectural style for designing network applications that communicate amongst each other. Unlike COBRA or SOAP, REST can be easily implemented on top of pure HTTP. REST-style architectures consist of clients and servers. The client calls the HTTP request method (POST, GET, PUT, or DELETE) to perform CRUD (created, read, update, and delete) operation over a resource that can be either a collection or a single element. In this recipe, we are going to architect an API of the REST server for the Billing application. How to do it... Follow these steps to architect an API of a RESTful service: 1. Define the base REST URI used by the client to access resources stored on the server; for example, it can look like http://example.com/resources. 2.


pages: 713 words: 93,944

Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement by Eric Redmond, Jim Wilson, Jim R. Wilson

AGPL, Amazon Web Services, business logic, create, read, update, delete, data is the new oil, database schema, Debian, domain-specific language, en.wikipedia.org, fault tolerance, full text search, general-purpose programming language, Kickstarter, Large Hadron Collider, linked data, MVC pattern, natural language processing, node package manager, random walk, recommendation engine, Ruby on Rails, seminal paper, Skype, social graph, sparse data, web application

INSERT INTO countries​​ ​​VALUES ('uk','United Kingdom');​​ ​​ERROR: duplicate key value violates unique constraint "countries_country_name_key"​​ ​​DETAIL: Key (country_name)=(United Kingdom) already exists.​​ On CRUD CRUD is a useful mnemonic for remembering the basic data management operations: Create, Read, Update, and Delete. These generally correspond to inserting new records (creating), modifying existing records (updating), and removing records you no longer need (deleting). All of the other operations you use a database for (any crazy query you can dream up) are read operations. If you can CRUD, you can do anything.

INSERT INTO cities​​ ​​VALUES ('Portland','87200','us');​​ ​​INSERT 0 1​​ This is a successful insert, to be sure. But we mistakenly entered the wrong postal_code. The correct postal code for Portland is 97205. Rather than delete and reinsert the value, we can update it inline. ​​UPDATE cities​​ ​​SET postal_code = '97205'​​ ​​WHERE name = 'Portland';​​ We have now Created, Read, Updated, and Deleted table rows. Join Reads All of the other databases we’ll read about in this book perform CRUD operations as well. What sets relational databases like PostgreSQL apart is their ability to join tables together when reading them. Joining, in essence, is an operation taking two separate tables and combining them in some way to return a single table.

Here’s a recap: Term Definition Column A domain of values of a certain type, sometimes called an attribute Row An object comprised as a set of column values, sometimes called a tuple Table A set of rows with the same columns, sometimes called a relation Primary key The unique value that pinpoints a specific row CRUD Create, Read, Update, Delete SQL Structured Query Language, the lingua franca of a relational database Join Combining two tables into one by some matching columns Left join Combining two tables into one by some matching columns or NULL if nothing matches the left table Index A data structure to optimize selection of a specific set of columns B-tree A good standard index; values are stored as a balanced tree data structure; very flexible Relational databases have been the de facto data management strategy for forty years—many of us began our careers in the midst of their evolution.


pages: 314 words: 94,600

Business Metadata: Capturing Enterprise Knowledge by William H. Inmon, Bonnie K. O'Neil, Lowell Fryman

affirmative action, bioinformatics, business cycle, business intelligence, business process, call centre, carbon-based life, continuous integration, corporate governance, create, read, update, delete, database schema, en.wikipedia.org, folksonomy, informal economy, knowledge economy, knowledge worker, semantic web, tacit knowledge, The Wisdom of Crowds, web application

Appendix Metadata System of Record Example Table 1 Metadata object system of record Meta Object Entity Name Entity Type Entity Definition Entity Scope Entity Active Ind Entity Logical Business Rule Logical Application Name Entity Synonym Name Logical Attribute Logical Attribute Definition Attribute Logical Business Rule Attribute Logical FK Ind Attribute Business Area Logical Business Function Data Subject Area Physical Column Name Physical Column Data Type Physical Column Length Physical Column Precision Strategic Modeling Tool Tactical Modeling Tool C C C C C U U C U DBMS Tool Data Integration Tool Reporting Tool U C C C C U C U C C U U C C U U C U C U C U C U (Cont.) 283 284 Appendix Table 1 Metadata object system of record (continued) Meta Object Strategic Modeling Tool Physical Column Decimal places Physical Column Default Value Physical Column Nullable Ind Physical Column Comment Physical Column Primary Key Ind Physical Column Foreign Key Ind Table Name Table Owner Table Type Table Comments Physical Table Name Physical Column Name Physical View Name Physical Database Name Physical Schema Name ETL Object Name Source Table Source Column Target Table Target Column ETL Job Name ETL Transformation Rule ETL Job Run Date ETL Job Execution Time ETL Job Row Count ETL Job Status Report Name Report Element Name Report Table Name Report Database Name Report DB Sequence Report Element Business Rule Tactical Modeling Tool DBMS Tool C U C U C U C U C C C C C U U U U U C C C C C Data Integration Tool Reporting Tool C R R R R C C C C C C C R R R R C Appendix 285 Metadata Usage Matrix Example The following table summarizes the metadata objects and the anticipated usage of each object in the following functions: Table 1 Summary of metadata objects usage Source – Metadata Object Entity Name Entity Type Entity Definition Entity Scope Entity Container Entity Active Ind Entity Logical Business Rule Logical Application Name Entity Synonym Name Logical Attribute Logical Attribute Definition Attribute Logical Business Rule Attribute Logical FK Ind Attribute Business Area Logical Business Function Data Subject Area Physical Column Name Physical Column Data Type Physical Column Length Physical Column Precision Physical Column Decimal Places Physical Column Default Value Physical Column Nullable Ind Data Lineage Impact Analysis Definition and or Glossary Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y (Cont.) 286 Appendix Table 1 Summary of metadata objects usage (continued) Source – Metadata Object Physical Column Comment Physical Column Primary Key Ind Physical Column Foreign Key Ind Table Name Table Owner Table Type Table Comments Physical Table Name Physical Column Name Physical View Name Physical Database Name Physical Schema Name ETL Object Name Source Table Source Column Target Table Target Column ETL Job Name ETL Transformation Rule ETL Job Run Date ETL Job Execution Time ETL Job Row Count ETL Job Status Report Name Report Element Name Report Table Name Report Database Name Report DB Sequence Report Element Business Rule Data Lineage Impact Analysis Definition and or Glossary Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Index Abstraction, linking structured and unstructured data, 230–231 Accuracy, metadata information, 33–34 Administration, infrastructure issues functionality requirements, 169 history keeping, 169–170 BI, see Business intelligence Broader term, definition component, 61, 63–64 Business Glossary features, 111–112 integrated technical and business metadata delivery, 152–153 Business intelligence (BI), business metadata delivery infrastructure, 163 Business metadata capture, see Capture, business metadata components, 13 definition, 38 delivery, see Delivery, business metadata funding, see Funding, business metadata historical perspective, 3–11 importance, 274–275 locations corporate forms, 15–16 reports, 14, 29–31 screens, 13–14 origins, 19–20 repository construction, see Metadata project resources, 281–282 technical metadata comparison, 12–13 conversion, 135–136, 182–186 infrastructure for integration, 165–166 separation, 140 tracking over time, 20–21 types, 158–160 Business rules business management, 238–239 business metadata, 237, 245 capturing rationale, 238–239 definition, 235–236 maintenance, 242 management, 243 metadata repository, 244–245 ruleflow, 242–243 sources, 237–238 systems, 239, 242–243 Call center volume, search problem quantification, 70 Capability Maturity Model Integration (CMMI), note-taking as asset producing, 265 Capture, business metadata barriers, 275 corporate knowledge base, 93–94 culture, 95–96 editing automation, 128–129 expansion of definition and descriptions, 129–131 granularization, 129 homonym resolution, 132–134 manual editing, 134–135 staging area, 134 synonym resolution, 131–132 Governance Lite™, 107–109, 111 individual documentation problem, 114–115 knowledge socialization, see Knowledge socialization metadata sources comparison of sources, 127 data warehouse, 126 database management system system catalogs, 124 documents, 123 enterprise resource planning applications, 122 extract-transform-load, 124–125 legacy systems, 125–126 on-line analytical processing tools, 124 on-line transaction processing, 125–126 reports, 122–123 spreadsheets, 123 principles, 95–96 publicity, 112–113 rationale, 90–93 technical metadata conversion to business metadata, 135–136 287 288 Index Capture, business metadata (Continued) technology search, 109–111 Web 2.0 folksonomy, 118–119 mashups, 115–116 overview, 115 Card catalog, see Library card catalog CDC, see Centers for Disease Control Centers for Disease Control (CDC), linking structured and unstructured data, 231 CIF, see Corporate Information Factory C-map, see Concept Map CMMI, see Capability Maturity Model Integration Collective intelligence, knowledge socialization, 97 Communications audits, 251 clarity problems bad business decisions, 57 English language limitations, 59 everyday communications, 56–57 faulty rollups, 57–58 units of measure differences, 59 classification, see Taxonomy definitions components, 61–62 guidelines, 60–61 importance, 59–60 miscellaneous guidelines, 64 usage notes, 62–64 historic library creation, 253 human/computer communication problem, 276–278 screening, 251–253 search problem information and knowledge workers, 65–66 information provider guidelines, 71–72 quantification, 67–70 search techniques, 71 tracking down information, 66–67 Compliance communications audits, 251 historic library creation, 253 screening, 251–253 data profiling, 254–256 financial audit metadata utility, 250 transaction background activities, 250–251 prospects, 280 Sarbanes-Oxley Act provisions, 248–240 types, 249–251 Concept Map (C-map), semantic framework, 205, 209 Conceptual model, semantic framework, 204 Controlled vocabulary (CV), semantic framework, 200–201 Corporate forms, business metadata content, 15–16 Corporate Information Factory (CIF), implementation, 81–82 Corporate knowledge base, components, 93–94 Create Read Update Delete (CRUD), conflict resolution, 167 CRM, see Customer relationship management Cross selling, business metadata capture rationale, 92 CRUD, see Create Read Update Delete Customer relationship management (CRM), business metadata capture rationale, 92 Customer, definition, 56 CV, see Controlled vocabulary DASD, see Direct access storage device Data, definition, 176 Database management system (DBMS) historical perspective, 5 metadata storage, 19 system catalog as metadata resource, 124 Data Flux, data quality presentation, 190–191 Data Governance Council, metadata stewardship, 42–43 Data quality continuum, 190 Data Warehousing report, 49 definition, 177 presentation, 189–190 Data Stewardship Council, metadata stewardship, 43–44 Data warehouse historical perspective, 7–9 infrastructure, 160–161 metadata resource, 126 metadata warehouse features, 161–162 DBMS, see Database management system Decision table, business rule representation, 239–242 Decision tree, business rule representation, 239, 241 Index Definition components, 61–62 dictionary role in information quality, 186 guidelines, 60–61 importance, 59–60 miscellaneous guidelines, 64 usage notes, 62–64 Delivery, business metadata examples corporate dictionary, 147–148 integrated technical and business metadata delivery, 152–153 mashups, 149–150 technical use, 151–152 training, 148–149 visual analytic techniques, 150–151 indirect usage accessibility from multiple places, 142–143 application access, 147 interactive reports, 145–146 overview, 141–142 Web delivery, 143–144 information quality business metadata, 188–190 infrastructure considerations business intelligence environments, 163 graphical affinity, 163–164 legacy environment, 162–163 mashups, 164 principles, 140–141 prospects, 280 Description Logics (DL), semantic framework, 206 Dictionary, see Glossary Direct access storage device (DASD), historical perspective, 4–6 Disk storage, historical perspective, 4–6 DL, see Description Logics Documents, metadata resource, 123 Editing, metadata automation, 128–129 expansion of definition and descriptions, 129–131 granularization, 129 homonym resolution, 132–134 manual editing, 134–135 staging area, 134 synonym resolution, 131–132 Employee turnover, business metadata capture rationale, 91–92 289 Enterprise resource planning (ERP), metadata resource, 85, 122 Entity/relationship (ER) model, semantic framework, 203–204, 208, 210–211 ER model, see Entity/relationship model ERP, see Enterprise resource planning ETL, see Extract-transform-load Extract-transform-load (ETL), metadata resource, 85, 124–125 Federated metadata, integrated metadata management, 168 Financial audit metadata utility, 250 transaction background activities, 250–251 First-order logic (FOL), semantic framework, 206 FOL, see First-order logic Folksonomy knowledge capture, 118–119 self-organizing tags, 77 Forms, see Corporate forms Fourth generation language historical perspective, 6–7 metadata handling, 11 Funding, business metadata advantages and disadvantages of approaches, 52–53 centralized implementation, 51 localized implementation, 51–52 overview, 50–51 Glossary business functions, 60 information quality role, 186 semantic framework, 201 Governance Lite™, knowledge capture, 107–109, 111 Granularization, metadata, 129 Graphical affinity, business metadata delivery infrastructure, 163–164 Grid, metadata representation, 18 Groupware, knowledge socialization, 100–103, 279 Homonyms, resolution, 132–134 Industrial recognition, text, 227 Information quality business and technical metadata interaction, 177–186 business metadata delivery, 188–190 290 Index Information quality (Continued) definition, 177 dictionary role, 186 methodology, 187–188 Information Technology (IT) department challenges, 278–279 metadata responsibility, 38–39 Information, definition, 177 IT department, see Information Technology department KB, see Knowledge base KM, see Knowledge management Knowledge base (KB) definition, 267 building, 267 Knowledge management (KM) business metadata intersection artifact generation, 262–263 corporate dictionary example, 263 definition, 260 goals, 260–261 importance, 261 social issues graying work force, 269–270 socialization effect on knowledge, 270 tacit knowledge, see Tacit knowledge techniques, 267–268 Knowledge socialization collective intelligence, 97 experts, 97–98 groupware, 100–103, 279 knowledge management, 268, 270 technology fostering portal and collaboration servers, 100–103 social networking, 99 wikis, 103–106 Knowledge worker metadata capture, 94 search problem, 65–66 Legacy systems business metadata delivery infrastructure, 162–163 metadata resource, 125–126 Library card catalog, metadata analogy, 27–29 Life cycle, metadata, 45–48 Magnetic tape data storage, 4 languages for data reading, 10 Mashup business metadata delivery, 149–150, 164 knowledge capture, 115–116 Master data management (MDM) conflict resolution, 167 overview, 22 MDM, see Master data management Metadata definition, 9, 26–27 examples, 9 grid representation, 18 management importance, 32 metamodel, 158–160 system of record example, 283–284 usage matrix example, 285–286 Metadata project business metadata versus technical metadata, 83–84 buying versus building, 170–172 classification, 82–83 funding, see Funding, business metadata iterations of development, 84 local metadata tools, 85 metadata sources, 86–87 preexisting repositories, 172–173 rationale, 80–82 scope defining, 85–87 Metadata Stewardship Council, responsibilities, 44–45 Narrower term, definition component, 61, 63–64 National Cancer Institute (NCI), semantic vocabulary implementation, 214–216 NCI, see National Cancer Institute Null, data profiling, 183, 185–186 ODS, see Operational data store OLAP, see Online analytical processing On-line analytical processing, metadata resource, 85124 On-line transaction processing, metadata resource, 125–126 Ontology, semantic framework, 207 Operational data store (ODS), data warehousing, 8 Opportunity cost, search problem quantification, 69 OWL, see Web Ontology Language Ownership, definition, 40 Patterns, identification, 183–184, 186 PC, see Personal computer Index Personal computer (PC) historical perspective, 7 metadata handling, 11 Preferred term, definition component, 62 Punch cards historical perspective, 4 metadata, 9–10 Quality, see Data quality; Information quality Range of values, data profiling, 183, 186 RDF, see Resource Definition Framework Reference file overview, 21–22 updating, 22 Regulations, see Compliance Related term, definition component, 61 Reports interactive reports, 145–146 metadata resource, 14, 29–31, 122–123 Repository, see Metadata project Resource Definition Framework (RDF), semantic framework, 204–205 Reuse, metadata, 32–33 Sales, search problem quantification, 70 Sarbanes-Oxley Act, provisions, 248–240 Screen, business metadata content, 13–14 Search problem enterprise search, 279 information and knowledge workers, 65–66 information provider guidelines, 71–72 quantification, 67–70 search techniques, 71 tracking down information, 66–67 Self-organizing map, linking structured and unstructured data, 233 Self-organizing tags, taxonomy, 77 Semantics business metadata delivering definitions and relationships, 208–209 exposing semantics to business, 210–211 expression, 209–210 overview, 207–208 context sensitivity, 197–199 framework Concept Map, 205, 209 conceptual model, 204 controlled vocabulary, 200–201 Description Logics, 206 291 entity/relationship model, 203–204, 208, 210–211 first-order logic, 206 glossary, 201 ontology, 207 Resource Definition Framework, 204–205 taxonomy, 202 thesauri, 203 topic map, 205 UML, 205–206 Web Ontology Language, 204–205, 210 human/computer concept, 199–200, 278 importance, 196–197 practical issues integration, 211–212 National Cancer Institute semantic vocabulary implementation, 214–216 service-oriented architecture, 214 Web Services, 212–213 prospects for integration and discovery, 280 semantic Web, 195–196 spectrum, 200–201, 208 Semistructured data, examples and technologies, 222–223 Serial transfer, knowledge management, 267–268 Service-oriented architecture (SOA) integrated metadata management, 168 semantics integration, 214 SOA, see Service-oriented architecture SOAP, semantic interface, 212 Socialization, see Knowledge socialization Social networking, knowledge socialization, 99 Spreadsheets, metadata resource, 123 Stemmed words, text distillation, 225 Stewardship business metadata approaches, 44–45 artifacts, 44 Data Governance Council, 42–43 Data Stewardship Council, 43–44 historical perspective, 41–42 Metadata Stewardship Council, 44–45 definition, 40–41 Structured metadata characteristics, 16–18 examples and technologies, 219–220 linking structured and unstructured data abstraction, 230–231 examples, 231, 233 292 Index Structured metadata (Continued) integration, 230 unstructured data comparison, 221 Synonyms, resolution, 131–132 Tacit knowledge definition, 94, 264 note-taking as asset producing, 265–266 transfer nurturing, 266 Taxonomy basic rules, 73, 75 document categorization, 76 governance and taxonomy, 77 language and vocabulary, 75–76 lowest common denominator, 75 overview, 72 self-organizing tags, 77 semantic framework, 202 simplicity, 76 Team Room, knowledge socialization, 100–103 Technical metadata business metadata comparison, 12–13 conversion, 135–136 infrastructure for integration, 165–166 separation, 140 categories, 2 Technical metadata conversion to business metadata, 135–136, 182–186 profiling, 179–182 Text business metadata terms, 227–228 communications audits, 252–253 distillation, 224–229 extraneous words, 225 industrial recognition, 227 pulling, 223 relationship recognition, 228–229 stemmed words, 225 word counting, 226 Thesauri, semantic framework, 203 Topic map, semantic framework, 205 UML, semantic framework, 205–206 Unstructured metadata characteristics, 16–18 examples and technologies, 220–221 mining prospects, 281 structured data comparison, 221 text business metadata terms, 227–228 distillation, 224–229 extraneous words, 225 industrial recognition, 227 pulling, 223 relationship recognition, 228–229 stemmed words, 225 word counting, 226 Value/frequency report, data profiling, 181, 184–186 Web 2.0 knowledge capture folksonomy, 118–119 mashups, 115–116 overview, 115 semantic Web, 195–196 Web Ontology Language (OWL), semantic framework, 204–205, 210 Web Services, semantics interface, 212–213 Wiki governance, 106 knowledge capture, 104 limitations, 105–106 portal collaboration comparison, 105 wikinomics, 104 Wikipedia, 103–104, 212 Words, see Text

It is valid to have optional means for creating the object, but the creation and maintenance processes should be established when requirements are being defined. Figure 3.5 presents an example of a system of record and maintenance matrix for a small number of metadata objects. Symbols used indicate the database operation performed on the metadata element specified (CRUD): ✦ C- Create ✦ R- Read ✦ U- Update ✦ D- Delete We have included a file entitled “Metadata SOR table example” on the Web site for this book, www.mkp.com/businessmetadata, as an example of a table that can be used to define the creation and maintenance life-cycle processes and tools for a set of metadata objects. 3.6 Business Metadata Data Quality Considerations Data quality may be the greatest challenge that enterprises face in managing the life cycle of business metadata.

The definitions are supposed to be created in the spreadsheet and copied to the database design tool, but a new data modeler joins the staff that doesn’t know anything about the spreadsheet. She maintains the definitions in the database design tool. The same situation often happens across tools; the definition may be created and maintained in both Cognos and the database design tool. Which takes precedence? One way to help resolve this problem is to create a CRUD (Create Read Update Delete) matrix illustrating tools and files that maintain metadata objects. See Table 9.1 for an example. We have included a file entitled “Metadata system of record table example” on the Web site for this book, www.mkp.com/businessmetadata, as an example of a table that can be used to define the creation and maintenance life-cycle processes and tools for a set of metadata objects. 9.5.3 Integration Technologies We have compared the metadata environment to a data warehouse and discussed the use of a physical metadata repository.


pages: 283 words: 78,705

Principles of Web API Design: Delivering Value with APIs and Microservices by James Higginbotham

Amazon Web Services, anti-pattern, business intelligence, business logic, business process, Clayton Christensen, cognitive dissonance, cognitive load, collaborative editing, continuous integration, create, read, update, delete, database schema, DevOps, fallacies of distributed computing, fault tolerance, index card, Internet of things, inventory management, Kubernetes, linked data, loose coupling, machine readable, Metcalfe’s law, microservices, recommendation engine, semantic web, side project, single page application, Snapchat, software as a service, SQL injection, web application, WebSocket

Common REST Design Patterns While covering REST API design patterns is the subject of a separate book, this section provides some basic patterns commonly encountered in REST-based API designs. Each of the following patterns offers an overview of when they should be applied to help API designers address commonly encountered design requirements. Create-Read-Update-Delete (CRUD) CRUD-based APIs refer to APIs that offer resource collections that contain instances. The resources instances will offer some or all of the create, read, update, and delete lifecycle pattern. The CRUD pattern may offer a complete or partial CRUD lifecycle around a resource collection and its instances in a consistent way. The CRUD pattern follows this familiar pattern: ■ GET /articles – List/paginate/filter the list of available articles ■ POST /articles – Create a new article ■ GET /articles/{articleId} – Retrieve the representation of an article instance ■ PUT /articles/{articleId} – Replace an existing article instance ■ PATCH /articles/{articleId} – Update specific fields (i.e., a selective update) for an article instance ■ DELETE /articles/{articleId} – Delete a specific article instance It is recommended to avoid fine-grained CRUD-based APIs result in multiple API calls that cross transactional boundaries.

Fielding’s paper are important when considering the design of a web-based API. When taken together, these constraints contribute to the design of evolvable web APIs. REST Was Never About CRUD As already mentioned, REST is not a specification or a protocol. Contrary to popular opinion, a REST-based API does not require JSON or the use of the create-read-update-delete (CRUD) pattern of data interaction. REST is simply a set of constraints and agreements on how the individual components should work together. This offers flexibility to address architectural issues. Many of today’s web-based APIs use JSON and the CRUD pattern as design elements. Unfortunately, a challenge emerges when people apply the REST label to an API that uses CRUD and JSON but may not intentionally apply the constraints as originally described in Dr.


Catalyst 5.8: The Perl MVC Framework by Antano Solar John, Jonathan Rockway, Solar John Antano

business logic, c2.com, create, read, update, delete, database schema, Debian, en.wikipedia.org, Firefox, MVC pattern, Ruby on Rails, social intelligence, web application

Finally, we added a database Model using DBIC::Schema and created a Controller containing actions that show data from the database, via the View and templates, as an HTML page. [ 39 ] Building a Real Application In this chapter, we're going to build our first real application—an address book. We'll start with a skeleton similar to the application from the last chapter, but then we'll add some real logic to create a CRUD (create, retrieve, update, delete) interface to a database. We'll learn how to define forms that automatically generate and validate themselves and how to design a database schema. We'll also use a View that generates common pages for us, so we won't have to worry about stylesheets or tricky HTML for now. Environment setup Before we start writing our new application, we'll need to create a skeleton again.


Python Web Development With Django by Jeff Forcier

business logic, create, read, update, delete, database schema, Debian, don't repeat yourself, duck typing, en.wikipedia.org, Firefox, full text search, functional programming, Guido van Rossum, loose coupling, MVC pattern, revision control, Ruby on Rails, Silicon Valley, slashdot, SQL injection, web application

Your initial database setup is now complete.The next time you run the syncdb command on this project (which you do any time you add an application or model), you see a bit less output because it doesn’t need to set up any of those tables a second time or prompt you to create a superuser. Setting Up the Automatic admin Application The automatic back-end application, or admin, has been described as Django’s “crown jewel.” For anyone who has tired of creating simple “CRUD” (Create, Read, Update, Delete) interfaces for Web applications, it’s a godsend.We get much deeper into the admin in “Customizing the Admin” in Chapter 11,“Advanced Django Programming.” For now, let’s just turn it on and poke around. Because it’s an optional part of Django, you need to specify in your settings.py file you’re using it—just like you did with your own blog app.


pages: 671 words: 228,348

Pro AngularJS by Adam Freeman

business logic, business process, create, read, update, delete, en.wikipedia.org, Google Chrome, information retrieval, inventory management, MVC pattern, place-making, premature optimization, revision control, Ruby on Rails, single page application, web application

To that end, I am going to use Deployd to define an administrator user and create the access policy described by Table 8-2. 187 Chapter 8 ■ SportsStore: Orders and Administration Table 8-2. The Access Control Policy for the Deployd Collections Collection Admin User products create, read, update, delete read orders create, read, update, delete create In short, the administrator should be able to perform any operation on any collection. The normal users should be able to read (but not modify) the products collection and create new objects in the orders collection (but not be able to see, modify, or delete them).

The model in an application built using the MVC pattern should • Contain the domain data • Contain the logic for creating, managing, and modifying the domain data (even if that means executing remote logic via web services) • Provide a clean API that exposes the model data and operations on it The model should not • Expose details of how the model data is obtained or managed (in other words, details of the data storage mechanism or the remote web service should not be exposed to controllers and views) • Contain logic that transforms the model based on user interaction (because this is the controller’s job) • Contain logic for displaying data to the user (this is the view’s job) The benefits of ensuring that the model is isolated from the controller and views are that you can test your logic more easily (I describe AngularJS unit testing in Chapter 25) and that enhancing and maintaining the overall application is simpler and easier. The best domain models contain the logic for getting and storing data persistently and for create, read, update, and delete operations (known collectively as CRUD). This can mean the model contains the logic directly, but more often the model will contain the logic for calling RESTful web services to invoke server-side database operations (which I demonstrate in Chapter 8 when I built a realistic AngularJS application and which I describe in detail in Chapter 21).

I requested a URL that I knew would return the JSON content I required.) ■■Tip Don’t worry if you are not familiar with JSON. I introduce it properly in Chapter 5. 51 Chapter 3 ■ Putting AngularJS in Context This approach can work well and is the foundation of RESTful web services, which use the nature of HTTP requests to perform create, read, update, and delete (CRUD) operations on data. ■■Note REST is a style of API rather than a well-defined specification, and there is disagreement about what exactly makes a web service RESTful. One point of contention is that purists do not consider web services that return JSON to be RESTful. Like any disagreement about an architectural pattern, the reasons for the disagreement are arbitrary and dull and not at all worth worrying about.


Scala in Action by Nilanjan Raychaudhuri

business logic, continuous integration, create, read, update, delete, database schema, domain-specific language, don't repeat yourself, duck typing, en.wikipedia.org, failed state, fault tolerance, functional programming, general-purpose programming language, higher-order functions, index card, Kanban, MVC pattern, type inference, web application

Contractor type ContractorPayrollVisitor contravariant, 2nd copy constructors copy method, 2nd core modules, Akka CostPlusCalculator() method countWords method covariance CPU core create a new Story screen create, read, update, delete. See CRUD operations. createDB method createSchema() method, 2nd CreateStory view object, 2nd, 3rd, 4th CRUD (create, read, update, delete) operations currentTime function currying functions cursor.hasNext() method, 2nd cursor.next() method, 2nd D d.getDays() method data loader data transfer object. See DTO. databases, for web applications saving to using Squeryl dataflow concurrency dataflow variables DataTables trait Date class DateTime.now() method DB class, 2nd, 3rd db method DB.apply(underlying.getDB(name)) function DB.scala file DB(underlying.getDB(name)) function DBCollection class, 2nd DBCollection.scala file DbConnection DBObject parameter declaring packages decorators def keyword default arguments default constructor default-afcdbe project DefaultHttpClient() method, 2nd DELETE method Delete method dependencies, in SBT DI (dependency injection), 2nd cake pattern implicit parameters in functional style structural typing using Spring framework dispatchers, in Akkaoogle application example distributed computing divide and conquer doctype documentation DogMood trait domain models, in Akkaoogle application example domains domain-specific See language DSL don’t-repeat-yourself code.

._ def client = new MongoClient def db = client.createDB("mydb") for(name <- db.collectionNames) println(name) This sample client creates a database called mydb and prints the names of all the collections under the database. If you run the code, it will print test and system.indexes, because by default MongoDB creates these two collections for you. Now you’re going to expose CRUD (create, read, update, delete) operations in the Scala driver so that users of your driver can work with documents. The following listing shows the Scala driver code you’ve written so far. Listing 3.3. Completed MongoClient.scala package com.scalainaction.mongo import com.mongodb._ class MongoClient(val host:String, val port:Int) { require(host !


pages: 628 words: 107,927

Node.js in Action by Mike Cantelon, Marc Harter, Tj Holowaychuk, Nathan Rajlich

Amazon Web Services, business logic, Chris Wanstrath, create, read, update, delete, Debian, en.wikipedia.org, Firefox, Google Chrome, machine readable, MITM: man-in-the-middle, MVC pattern, node package manager, p-value, pull request, Ruby on Rails, SQL injection, web application, WebSocket

Content-Disposition header Content-Length header, 2nd Content-Type header, 2nd, 3rd, 4th, 5th, 6th contexts, 2nd controller (MVC) cookieParser() middleware JSON cookies outgoing cookies overview regular cookies signed cookies core, Node CouchDB COUNT option cp.exec() function cp.fork() function cp.spawn() function create method create, read, update, delete. See CRUD. createClient method, 2nd createServer method, 2nd cross-site scripting. See XSS. CRUD (create, read, update, delete) CSRF (cross-site request forgery) protection middleware _csrf property Ctrl-C keyboard shortcut, 2nd, 3rd cursor custom filters in EJS Cygwin, 2nd D data argument data event, 2nd, 3rd, 4th data stores in sessions Datagram module data-intensive real-time (DIRTy) applications DBMS (database management system) db-oracle module DEBUG environment variable, 2nd debug function, 2nd debug keyword debug module, 2nd debugging analyzing code with JSHint built-in debugger examining state in navigation overview Node Inspector examining state in navigation starting with console module outputting application status information outputting stack traces outputting timing information with debug module dedicated servers deepEqual assertion default statements DELETE requests dependencies installing specifying describe function, 2nd /dev/js0 dir function directory listing middleware directory traversal attack directory() middleware, 2nd __dirname variable, 2nd, 3rd DIRTy (data-intensive real-time) applications disable method disconnections, handling unclean dispatcher distributed version control system.

Those are left for third-party modules to provide. Now that you’ve seen the basic HTTP API, it’s time to put it to use. In the next section, you’ll make a simple, HTTP-compliant application using this API. 4.2. Building a RESTful web service Suppose you want to create a to-do list web service with Node, involving the typical create, read, update, and delete (CRUD) actions. These actions can be implemented in many ways, but in this section we’ll focus on creating a RESTful web service—a service that utilizes the HTTP method verbs to expose a concise API. In 2000, representational state transfer (REST) was introduced by Roy Fielding,[1] one of the prominent contributors to the HTTP 1.0 and 1.1 specifications.


Writing Effective Use Cases by Alistair Cockburn

business process, c2.com, create, read, update, delete, finite state, index card, information retrieval, iterative process, operational security, recommendation engine, Silicon Valley, web application, work culture

Depending on the number of use cases in these clusters, I would summarize work progress using clusters of related or summary use cases. 145 Chapter 14. Two Special Use Cases CRUD use cases - Page 146 14. TWO S PECIAL U SE C ASES 14.1 CRUD use cases There is not yet a consensus on how to organize all those little use cases of the sort, Create a Frizzle, Retrieve a Frizzle, Update a Frizzle, Delete a Frizzle. These are known as CRUD use cases, from the Create, Retrieve, Update, Delete operations on databases. The question is, are they all part of one bigger use case, Manage Frizzles, or are they separate use cases? In principle, they are three use cases, because each is a separate goal, possibly carried out by a different person with a different security level.


pages: 134 words: 29,488

Python Requests Essentials by Rakesh Vidya Chandra, Bala Subrahmanyam Varanasi

business logic, create, read, update, delete, en.wikipedia.org, Kickstarter, machine readable, MITM: man-in-the-middle, MVC pattern, natural language processing, RFC: Request For Comment, RFID, supply-chain management, web application

For that, we need to call the method create_all(), which is present in the database instance — db. In our application, we generally call this function before invoking the server defined in runserver.py file. Querying database models Now, we have the database models ready. Let us query the data from the database using the SQLAlchemy's ORM. We'll perform the basic create, retrieve, update, and delete (CRUD) operations on our database instance — db. Before making queries, let us move to our project root directory and fire up the Python console to execute the following commands: >>> from survey import app, db >>> from survey.models import Question Now, let us create a Question object in the database.

Add the following code to the survey/templates/vote.html file: {% extends "base.html" %} {% block content %} <div> [ 103 ] Implementing a Web Application with Python Using Flask <p> {% if question %} <p>{{ question.question_text }}</p> <form action="/questions/{{ question.id }}/vote" method="POST"> <input type="radio" name="vote" value="yes">Yes<br> <input type="radio" name="vote" value="no">No<br> <input type="radio" name="vote" value="maybe">Maybe<br> <input type="submit" value="Submit" /><br> </form> <p><a href="/questions/{{ question.id }}">Back to Question</a></p> {% else %} Not match found! {% endif %} </p> </div> <hr /> {% endblock %} Running the survey application Hurray! We succeeded in creating an application which will allow the users to create a survey, retrieve a survey, update a survey, delete a survey, and cast the vote of a choice for a survey. Perform the following steps for running the server: 1. Before running the server, let us go ahead and fill the contents of server.py with the following code: import sys from survey import app, db from survey import views def main(): db.create_all() app.run(debug=True) return 0 if __name__ == '__main__': sys.exit(main()) [ 104 ] Chapter 7 2.


pages: 458 words: 46,761

Essential Sqlalchemy by Jason Myers, Rick Copeland

create, read, update, delete, database schema, microservices, Ruby on Rails, side project, SQL injection, web application

Partial text query from sqlalchemy import text stmt = select([users]).where(text("username='cookiemon'")) print(connection.execute(stmt).fetchall()) This results in: [(1, None, u'cookiemon', u'mon@cookie.com', u'111-111-1111', u'password', datetime.datetime(2015, 3, 30, 13, 48, 25, 536450), datetime.datetime(2015, 3, 30, 13, 48, 25, 536457)) ] Now you should have an understanding of how to use the SQL Expression Language to work with data in SQLAlchemy. We explored how to create, read, update, and delete operations. This is a good point to stop and explore a bit on your own. Try to create more cookies, orders, and line items, and use query chains to group them by order and user. Now that you’ve explored a bit more and hopefully broken something, let’s investigate how to react to exceptions raised in SQLAlchemy, and how to use transactions to group statements that must succeed or fail as a group.

Partial text query from sqlalchemy import text query = session.query(User).filter(text("username='cookiemon'")) print(query.all()) Example 7-31 results in: [User(username='cookiemon', email_address='mon@cookie.com', phone='111-111-1111', password='password')] Now you should have an understanding of how to use the ORM to work with data in SQLAlchemy. We explored how to create, read, update, and delete operations. This is a good point to stop and explore a bit on your own. Try to create more cookies, orders, and line items, and use query chains to group them by order and user. Now that you’ve explored a bit more and hopefully broken something, let’s investigate how to react to exceptions raised in SQLAlchemy, and how to use transactions to group statements that must succeed or fail as a group.


pages: 602 words: 207,965

Practical Ext JS Projects With Gears by Frank Zammetti

a long time ago in a galaxy far, far away, Albert Einstein, corporate raider, create, read, update, delete, database schema, en.wikipedia.org, fake news, Firefox, full text search, Gordon Gekko, Kickstarter, Larry Wall, leftpad, loose coupling, Ronald Reagan, web application

As it turns out, this is the only retrieval operation we’ll need in this application, so it really is as simple as that. Finally, there is an SQL statement used to delete a note. All this takes is an ID value for the note to delete, again using dynamic parameters. The U iN CRUD If you’ve never heard the term CRUD before, now you have! CRUD stands for Create, Retrieve, Update, and Delete. These are the four basic operations that most database-driven applications need, and CRUD is a very common term in programming circles. It’s also kind of fun to say, especially in place of more vulgar… er… vulgarities! So, we can see here that there is a create SQL statement, a retrieve statement, and a delete statement for notes, but no update statement.

Table structure of the tasks table 205 206 Ch apt er 4 ■ Ma K ING p r OJ eC t Ma Na G eMeN t C O O L: t I M e K e e p e r e X t Figure 4-7. Table structure of the resources table For each of the entities there are five SQL statements: one to create the associated table and one for each of the CRUD (Create, Retrieve, Update, and Delete) operations. So for example, there are sqlCreateProjectsTable, sqlCreateProject, sqlRetrieveProjects, sqlUpdateProject, and sqlDeleteProject fields, and there are five fields for tasks and five for resources. The statements are about as you would expect. For example, here are the statements pertaining to projects: var sqlCreateProjectsTable = "CREATE TABLE IF NOT EXISTS projects (" + "name TEXT, description TEXT, projectmanager TEXT, " + "startdate TEXT, enddate TEXT, allocatedhours INT)" var sqlCreateProject = "INSERT INTO projects (name, description, projectmanager, " + "startdate, enddate, allocatedhours) VALUES (?

See widgets configuration options, for widgets, 60 confirm() method, 290, 548 console.log() method, 42 constrain() method, 31 constructor property, 279 constructors, 60 ContactRecord field, 154 contacts (OrganizerExt sample application), 131, 141, 147–152 Accordion layout for, 175 filtering by status, 178 contactsStore field, 154 Container class, 58, 62 containers, 62–75 menus and, 89 for OrganizerExt sample application, 170, 171, 179 content property, 151 CookieProvider() method, 118, 336, 339 CabinetExt sample application and, 281 SQL Workbench sample application and, 380 copy() method, 216, 224 copy operation, databases and, 411–415 create() method, 101, 161 createAccount() method, 515 createActivity() method, 516 createAndPositionIndicators() method, 452, 460 createCardDescriptor() method, 460 createCardStackImages() method, 452, 458 createCategory() method, 268, 288 createDataStores() method, 157, 158 createInterceptor() method, 30 createNewAppointmentDialog() method, 157 createNewContactDialog() method, 157 createNewNoteDialog() method, 157, 163 createNewTaskDialog() method, 157 createNote() method, 150, 159, 165 createPortfolio() method, 514 createProject() method, 207, 237 createRecordDescriptors() method, 157 createSequence() method, 30 createSnippet() method, 270 createStyleSheet() method, 44 createTableExecute() method, 399 createTable() method, 398 CreateTableWindow.js, 397–403 createWorkerFromUrl() method, 486 createWorker() method, 486 critical chain methodology, 196 critical path schedules, 196 CRUD (Create, Retrieve, Update, and Delete) OrganizerExt sample application and, 146 TimekeeperExt sample application and, 206 CSS class, 44 CSS selector queries, 39 cssAbout class, 378 cssAbout selector, 141, 202 cssAltRow selector, 326 cssDDHover class, 447 cssDDNoHover class, 447 561 562 nINDEX cssDefault selector, 141 cssDetailsTable selector, 142 cssPleaseWait selector CabinetExt sample application and, 264, 278 OrganizerExt sample application and, 141 TimekeeperExt sample application and, 202 cssProgressBarFill selector, 203 cssSource class, 377, 447 cssSource selector CabinetExt sample application and, 264 OrganizerExt sample application and, 141 TimekeeperExt sample application and, 202 cssSummaryTableHeader selector, 202 cssSummaryTitle selector, 202 cssTableCell class, 378, 409, 428 cssTableCentered class, 378, 399, 406 cssTableHeader class, 378, 399, 406, 427 currentCategory field, 153 D DAO class, 144–152, 203 DAO.js file for CabinetExt sample application, 262, 265–272 for LocalBusinessSearch sample application, 327 for OrganizerExt sample application, 133, 144 for TimekeeperExt sample application, 203–209 data binding, 94, 101 data stores.


pages: 201 words: 63,192

Graph Databases by Ian Robinson, Jim Webber, Emil Eifrem

Amazon Web Services, anti-pattern, bioinformatics, business logic, commoditize, corporate governance, create, read, update, delete, data acquisition, en.wikipedia.org, fault tolerance, linked data, loose coupling, Network effects, recommendation engine, semantic web, sentiment analysis, social graph, software as a service, SPARQL, the strength of weak ties, web application

Most of the popular graph data‐ bases on the market use the property graph model, and in consequence, it’s the model we’ll use throughout the remainder of this book. Graph Databases A graph database management system (henceforth, a graph database) is an online da‐ tabase management system with Create, Read, Update and Delete methods that expose a graph data model. Graph databases are generally built for use with transactional (OLTP) systems. Accordingly, they are normally optimized for transactional perfor‐ mance, and engineered with transactional integrity and operational availability in mind. There are two properties of graph databases you should consider when investigating graph database technologies: 1.

We can use them for that purpose, but we have to add code to fill in where the underlying data model leaves off, resulting in a development experience that is far from seamless, and opertional characteristics that are generally speaking not very fast, particularly as the number of hops (or “degree” of the query) increases. Aggregate stores may be good at strong data that’s big, but they aren’t generally that great at dealing with problems that require an understanding of how things are connected. Graph Databases A graph database is an online (“real-time”) database management system with Create, Read, Update and Delete (CRUD) methods that expose a graph data model. Graph da‐ tabases are generally built for use with transactional (OLTP) systems. Accordingly, they are normally optimized for transactional performance, and engineered with transac‐ tional integrity and operational availability in mind. Two properties of graph databases are useful to understand when investigating graph database technologies: 1.


Django Book by Matt Behrens

Benevolent Dictator For Life (BDFL), book value, business logic, create, read, update, delete, database schema, distributed revision control, don't repeat yourself, duck typing, en.wikipedia.org, Firefox, full text search, loose coupling, MITM: man-in-the-middle, MVC pattern, revision control, Ruby on Rails, school choice, slashdot, SQL injection, web application

# models.py (the database tables) from django.db import models class Book(models.Model): name = models.CharField(max_length=50) pub_date = models.DateField() # views.py (the business logic) from django.shortcuts import render from models import Book def latest_books(request): book_list = Book.objects.order_by('-pub_date')[:10] return render(request, 'latest_books.html', {'book_list': book_list}) # urls.py (the URL configuration) from django.conf.urls.defaults import * import views urlpatterns = patterns('', (r'^latest/$', views.latest_books), ) # latest_books.html (the template) <html><head><title>Books</title></head> <body> <h1>Books</h1> <ul> {% for book in book_list %} <li>{{ book.name }}</li> {% endfor %} </ul> </body></html> Again, don’t worry about the particulars of syntax; just get a feel for the overall design. The main thing to note here is the separation of concerns: The models.py file contains a description of the database table, represented by a Python class. This class is called a model. Using it, you can create, retrieve, update and delete records in your database using simple Python code rather than writing repetitive SQL statements. The views.py file contains the business logic for the page. The latest_books() function is called a view. The urls.py file specifies which view is called for a given URL pattern. In this case, the URL /latest/ will be handled by the latest_books() function.

© Copyright 2012, Matt Behrens. Created using Sphinx 1.2.2. index next | previous | Django Book 0.1 documentation » Chapter 10: Advanced Models In Chapter 5, we presented an introduction to Django’s database layer – how to define models and how to use the database API to create, retrieve, update and delete records. In this chapter, we’ll introduce you to some more advanced features of this part of Django. Related Objects Recall our book models from Chapter 5: from django.db import models class Publisher(models.Model): name = models.CharField(max_length=30) address = models.CharField(max_length=50) city = models.CharField(max_length=60) state_province = models.CharField(max_length=30) country = models.CharField(max_length=50) website = models.URLField() def __unicode__(self): return self.name class Author(models.Model): first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=40) email = models.EmailField() def __unicode__(self): return u'%s %s' % (self.first_name, self.last_name) class Book(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author) publisher = models.ForeignKey(Publisher) publication_date = models.DateField() def __unicode__(self): return self.title As we explained in Chapter 5, accessing the value for a particular field on a database object is as straightforward as using an attribute.


pages: 485 words: 74,211

Developing Web Applications with Haskell and Yesod by Michael Snoyman

create, read, update, delete, database schema, Debian, domain-specific language, don't repeat yourself, full text search, functional programming, MVC pattern, web application

Maybe “added” will be constructed differently depending whether you added 1 or more turtles. There are a bunch of whitespace issues as well. So the general rule is: translate entire phrases, not just words. Chapter 17. Creating a Subsite How many sites provide authentication systems? Or need to provide Create, Read, Update, Delete (CRUD) management of some objects? Or a blog? Or a wiki? The theme here is that many websites include common components that can be reused throughout multiple sites. However, it is often quite difficult to get code to be modular enough to be truly plug-and-play: a component will require hooks into the routing system, usually for multiple routes, and will need some way of sharing styling information with the master site.


pages: 282 words: 85,658

Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century by Jeff Lawson

Airbnb, AltaVista, Amazon Web Services, barriers to entry, big data - Walmart - Pop Tarts, Big Tech, big-box store, bitcoin, business process, call centre, Chuck Templeton: OpenTable:, cloud computing, coronavirus, COVID-19, create, read, update, delete, cryptocurrency, data science, David Heinemeier Hansson, deep learning, DevOps, Elon Musk, financial independence, global pandemic, global supply chain, Hacker News, Internet of things, Jeff Bezos, Kanban, Lean Startup, loose coupling, Lyft, Marc Andreessen, Marc Benioff, Mark Zuckerberg, microservices, minimum viable product, Mitch Kapor, move fast and break things, Paul Graham, peer-to-peer, ride hailing / ride sharing, risk tolerance, Ruby on Rails, Salesforce, side project, Silicon Valley, Silicon Valley startup, Skype, social distancing, software as a service, software is eating the world, sorting algorithm, Startup school, Steve Ballmer, Steve Jobs, Telecommunications Act of 1996, Toyota Production System, transaction costs, transfer pricing, two-pizza team, Uber and Lyft, uber lyft, ubercab, web application, Y Combinator

Lisa helped Chris understand why people needed the code he was writing, and how it would help them. After he built empathy, the act of writing this simple workflow application was trivial. User Empathy = Better Products, Faster The truth is that most software is pretty simple. It’s what developers call CRUD applications: Create, Read, Update, Delete. Most apps online are forms that let the user input data, modify data, report out data, or delete data. Nearly every website or mobile app you’ve ever used is 95 percent CRUD operations. This isn’t rocket science. What that means is that the real difference in how long it takes to solve a problem, and how well it’s solved, comes from the developer understanding the problem, as Ozone did.


pages: 239 words: 64,812

Geek Sublime: The Beauty of Code, the Code of Beauty by Vikram Chandra

Alan Turing: On Computable Numbers, with an Application to the Entscheidungsproblem, Apple II, barriers to entry, Berlin Wall, Big Tech, British Empire, business process, Californian Ideology, Charles Babbage, conceptual framework, create, read, update, delete, crowdsourcing, don't repeat yourself, Donald Knuth, East Village, European colonialism, finite state, Firefox, Flash crash, functional programming, glass ceiling, Grace Hopper, Hacker News, haute couture, hype cycle, iterative process, Jaron Lanier, John von Neumann, land reform, London Whale, Norman Mailer, Paul Graham, pink-collar, revision control, Silicon Valley, Silicon Valley ideology, Skype, Steve Jobs, Steve Wozniak, supercomputer in your pocket, synthetic biology, tech worker, the Cathedral and the Bazaar, theory of mind, Therac-25, Turing machine, wikimedia commons, women in the workforce

I set up computers for elegant ladies in River Oaks and gave them word-processing lessons; I went out to factories and offices in the hinterlands of Houston to observe assembly lines and then modeled workflows and production processes. The programming I did was journeyman work; I mostly wrote CRUD applications, menu-driven screens that let the users Create, Retrieve, Update, and Delete records that tracked whatever product or service they provided: precision-engineered drill parts for high-heat applications, workers for the oil industry, reservations at restaurants. Simple stuff, but useful, and I always felt like I was learning, and making good money, sometimes even great money.


pages: 446 words: 102,421

Network Security Through Data Analysis: Building Situational Awareness by Michael S Collins

business process, cloud computing, create, read, update, delete, data science, Firefox, functional programming, general-purpose programming language, index card, information security, Internet Archive, inventory management, iterative process, operational security, OSI model, p-value, Parkinson's law, peer-to-peer, slashdot, statistical model, zero day

Choosing the right data system is a function of the volume of data stored, the type of data stored, and the population that’s going to analyze it. There is no single right choice, and depending on the combination of queries expected and data stored, each of these strategies can be the best. Log Data and the CRUD Paradigm The CRUD (create, read, update, and delete) paradigm describes the basic operations expected of a persistent storage system. Relational database management systems (RDBMS), the most prevalent form of persistent storage, expect that users will regularly and asynchronously update existing contents. Relational databases are primarily designed for data integrity, not performance.

Cookie header, HTTP: CLF and ELF country code TLD (ccTLD), DNS Name Structure country_codes.pmap, pmaps CPE (Common Platform Enumeration), The NVD, Malware Sites, and the C*Es CRAN (Comprehensive R Archive Network), Installation and Setup crawlers, HTTP Fumbling CRUD (create, read, update and delete) paradigm, Log Data and the CRUD Paradigm CVE (Common Vulnerabilities and Exposures) database, The NVD, Malware Sites, and the C*Es D dark space, Lookup Failures, Identifying Dark Space data collection host/service sensors, Host and Service Sensors: Logging Traffic at the Source–Syslog network sensors, Network Sensors–NetFlow Generation and Collection sensors/detectors, Sensors and Detectors: An Introduction–Actions: What a Sensor Does with Data data collection, need for hybrid sources, Data, The Goal of EDA: Applying Analysis data frames accessing, Data Frames creation of, Data Frames data partitioning, Creating a Well-Organized Flat File System: Lessons from SiLK, Data Selection data storage, Data Storage for Analysis: Relational Databases, Big Data, and Other Options–Storage Hierarchy, Query Times, and Aging centralized vs. streaming analytics, What Storage Approach to Use comparisons of, A Brief Introduction to NoSQL Systems data fusion, Storage Hierarchy, Query Times, and Aging design goals, Data flat file systems, Creating a Well-Organized Flat File System: Lessons from SiLK log data vs.


pages: 540 words: 103,101

Building Microservices by Sam Newman

airport security, Amazon Web Services, anti-pattern, business logic, business process, call centre, continuous integration, Conway's law, create, read, update, delete, defense in depth, don't repeat yourself, Edward Snowden, fail fast, fallacies of distributed computing, fault tolerance, index card, information retrieval, Infrastructure as a Service, inventory management, job automation, Kubernetes, load shedding, loose coupling, microservices, MITM: man-in-the-middle, platform as a service, premature optimization, pull request, recommendation engine, Salesforce, SimCity, social graph, software as a service, source of truth, sunk-cost fallacy, systems thinking, the built environment, the long tail, two-pizza team, web application, WebSocket

The warehouse may provide the capability to get a current stock list, for example, or the finance context may well expose the end-of-month accounts or let you set up payroll for a new recruit. These capabilities may require the interchange of information — shared models — but I have seen too often that thinking about data leads to anemic, CRUD-based (create, read, update, delete) services. So ask first “What does this context do?”, and then “So what data does it need to do that?” When modeled as services, these capabilities become the key operations that will be exposed over the wire to other collaborators. Turtles All the Way Down At the start, you will probably identify a number of coarse-grained bounded contexts.


Programming Android by Zigurd Mednieks, Laird Dornin, G. Blake Meike, Masumi Nakamura

anti-pattern, business process, conceptual framework, create, read, update, delete, database schema, Debian, domain-specific language, en.wikipedia.org, fault tolerance, general purpose technology, Google Earth, interchangeable parts, iterative process, loose coupling, MVC pattern, revision control, RFID, SQL injection, systems thinking, web application

A special URI starting with the content://, which is recognized across the local device, gives you access to the content provider data. To use a ContentProvider, you specify a URI and how to act on referenced data. Here is a list of content provider operations, which provide the well-known quartet of basic data handling activities: create (insert), read (query), update, and delete: Insert The insert method of the ContentProvider class is analogous to the REST POST operation. It inserts new records into the database. Query The query method of the ContentProvider class is analogous to the REST GET operation. It returns a set of records in a specialized collection class called Cursor.

You will find that writing database code in Android is usually an iterative process of writing Java code to manipulate tables, and then peeking at created data using the command line. SQL Data Definition Commands Statements in the SQL language fall into two distinct categories: those used to create and modify tables—the locations where data is stored—and those used to create, read, update, and delete the data in those tables. In this section we’ll look at the former, the data definition commands: CREATE TABLE Developers start working with SQL by creating a table to store data. The CREATE TABLE command creates a new table in an SQLite database. It specifies a name, which must be unique among the tables in the database, and various columns to hold the data.

For a given URI query, a client does not know which application will provide the data; it simply presents the OS with a URI and leaves it to the platform to start the appropriate application to provide the result. The platform also provides a permission that allows clients to limit access to content provider data. The content provider API enables full create, read, update, and delete access to shared content. This means applications can use URI-oriented requests to: Create new records Retrieve one, all, or a limited set of records Update records Delete records This chapter shows you how to write your own content provider by examining the inner workings of an example content provider, SimpleFinchVideoContentProvider, included within the Finch source tree.


When Computers Can Think: The Artificial Intelligence Singularity by Anthony Berglas, William Black, Samantha Thalind, Max Scratchmann, Michelle Estes

3D printing, Abraham Maslow, AI winter, air gap, anthropic principle, artificial general intelligence, Asilomar, augmented reality, Automated Insights, autonomous vehicles, availability heuristic, backpropagation, blue-collar work, Boston Dynamics, brain emulation, call centre, cognitive bias, combinatorial explosion, computer vision, Computing Machinery and Intelligence, create, read, update, delete, cuban missile crisis, David Attenborough, DeepMind, disinformation, driverless car, Elon Musk, en.wikipedia.org, epigenetics, Ernest Rutherford, factory automation, feminist movement, finite state, Flynn Effect, friendly AI, general-purpose programming language, Google Glasses, Google X / Alphabet X, Gödel, Escher, Bach, Hans Moravec, industrial robot, Isaac Newton, job automation, John von Neumann, Law of Accelerating Returns, license plate recognition, Mahatma Gandhi, mandelbrot fractal, natural language processing, Nick Bostrom, Parkinson's law, patent troll, patient HM, pattern recognition, phenotype, ransomware, Ray Kurzweil, Recombinant DNA, self-driving car, semantic web, Silicon Valley, Singularitarianism, Skype, sorting algorithm, speech recognition, statistical model, stem cell, Stephen Hawking, Stuxnet, superintelligent machines, technological singularity, Thomas Malthus, Turing machine, Turing test, uranium enrichment, Von Neumann architecture, Watson beat the top human players on Jeopardy!, wikimedia commons, zero day

This involves logic to display a list of customers that satisfies various criteria, then provide a blank form to enter a new customer’s details or select a customer record for editing, and then insert, update or delete the Customer record in a database. This type of logic is generally referred to as CRUD — Create Read Update Delete. CRUDing a customer is much the same as CRUDing an order, student, subject, employee or product, only the data table, fields and declarative business rules are different. The few systems that use these high-level models can be used to implement fairly complex information systems involving dozens of tables without any explicit programming being required at all.


pages: 190 words: 52,865

Full Stack Web Development With Backbone.js by Patrick Mulder

Airbnb, business logic, create, read, update, delete, Debian, functional programming, Kickstarter, MVC pattern, node package manager, Ruby on Rails, side project, single page application, web application, WebSocket

. • Last, we must set some HTTP headers, such as content-type, so that the interpre‐ tation at the other end of the line understands what is going on. The HTTP headers are also managed by Backbone.Sync. Backbone.Sync manages actions for writing and reading data from a server. For this, Backbone defines its own verbs: create, read, update, and delete with the following mappings to the routes of a RESTful API: Backbone verb vs RESTful API endpoint create movie <--> POST /movies read movie <--> GET /movies[/id] update movie <--> PUT /movies/id delete movie <--> DELETE /movies/id By default, Backbone.Sync expects the JSON going and coming from a server to comply with the following pattern: [{ 'id': 1, 'title: 'The Artist', ... }, ... ] 88 | Chapter 7: Synchronizing State This means that you don’t have root elements indicating the name of the movies col‐ lection, for example.


pages: 603 words: 141,814

Python for Unix and Linux System Administration by Noah Gift, Jeremy M. Jones

Amazon Web Services, bash_history, Bram Moolenaar, business logic, cloud computing, create, read, update, delete, database schema, Debian, distributed revision control, Firefox, functional programming, Guido van Rossum, industrial robot, inventory management, job automation, Mark Shuttleworth, MVC pattern, skunkworks, web application

Note that l.add_s is what shows us that we are making an ansynchronous call to the API. These are the basics for using Python and LDAP together, but you should refer to the resources given at the beginning of the chapter for further information about using python-ldap. Specifically, there are examples that detail LDAPv3; Create, Read, Update, Delete (CRUD); and more. One final thing to mention is that there is a tool aptly named web2ldap, and it is a Python, web-based frontend for LDAP by the same author of python-ldap. You might consider trying it out as well as an alternative to some of the other web-based management solutions for LDAP.


pages: 480 words: 99,288

Mastering ElasticSearch by Rafal Kuc, Marek Rogozinski

Amazon Web Services, book value, business logic, create, read, update, delete, en.wikipedia.org, fault tolerance, finite state, full text search, information retrieval

Note Please note that you are not forced to run the actionGet() method after the execute() method, just like we discussed in the Anatomy of the API section of this chapter. If you are interested in asynchronous behavior, you can still use the futures. CRUD operations We will have a closer look into the API operations, the CRUD (create, retrieve, update, and delete document) commands. Let's begin from the retrieve document call. Fetching documents Let's begin from the retrieve document call. We've already seen the following example when we discussed API anatomy: GetResponse response = client .prepareGet("library", "book", "1") .setFields("title", "_source") .execute().actionGet(); While in preparation, after setting the index name, type name (may be null if we don't care what the type is), and identifier we will have the tool object.


Learning Flask Framework by Matt Copperwaite, Charles Leifer

create, read, update, delete, database schema, Debian, DevOps, don't repeat yourself, duck typing, full text search, place-making, Skype, SQL injection, web application

Open the main.py module and add the following: from flask import request, session from app import app, db import admin # This line is new, placed after the app import. import models import views You should now be able to start the development server and navigate to /admin/ to view a barebones admin–the default dashboard, as seen in the following image: [ 125 ] Building an Administrative Dashboard As you progress through this chapter, we will turn this boring and plain admin interface into a rich and powerful dashboard for managing your blog. Exposing models through the Admin Flask-Admin comes with a contrib package that contains special view classes designed to work with SQLAlchemy models. These classes provide out-of-the-box create, read, update, and delete functionalities. Open admin.py and update the following code: from flask.ext.admin import Admin from flask.ext.admin.contrib.sqla import ModelView from app import app, db from models import Entry, Tag, User admin = Admin(app, 'Blog Admin') admin.add_view(ModelView(Entry, db.session)) admin.add_view(ModelView(Tag, db.session)) admin.add_view(ModelView(User, db.session)) Note how we call admin.add_view() and pass instances of the ModelView class, as well as the db session, for it to access the database with.


pages: 292 words: 66,588

Learning Vue.js 2: Learn How to Build Amazing and Complex Reactive Web Applications Easily With Vue.js by Olga Filipova

Amazon Web Services, business logic, continuous integration, create, read, update, delete, en.wikipedia.org, Firefox, Google Chrome, leftpad, MVC pattern, pull request, side project, single page application, single source of truth, Skype, source of truth, web application

To create a resource using the vue-resource plugin, we just call a resource method on Vue and pass the URL to it: const ShoppingListsResource = Vue.resource('http://localhost:3000/' + 'shoppinglists{/id}') The ShoppingListsResource constant now exposes all the methods needed for the implementation of CRUD (Create, Read, Update, and Delete) operations. It is so easy to use that we could basically export the resource itself. But let's export nice methods for each of the CRUD operations: export default { fetchShoppingLists: () => { return ShoppingListsResource.get() }, addNewShoppingList: (data) => { return ShoppingListsResource.save(data) }, updateShoppingList: (data) => { return ShoppingListsResource.update({ id: data.id }, data) }, deleteShoppingList: (id) => { return ShoppingListsResource.remove({ id: id }) } } The full code for the api/index.js file can be seen in this gist at https://gist.github.com/chudaol/d5176b88ba2c5799c0b7b0dd33ac0426 .


pages: 232 words: 71,237

Kill It With Fire: Manage Aging Computer Systems by Marianne Bellotti

anti-pattern, barriers to entry, business logic, cloud computing, cognitive bias, computer age, continuous integration, create, read, update, delete, Daniel Kahneman / Amos Tversky, data science, database schema, Dennis Ritchie, DevOps, fault tolerance, fear of failure, Google Chrome, Hans Moravec, iterative process, Ken Thompson, loose coupling, microservices, minimum viable product, Multics, no silver bullet, off-by-one error, platform as a service, pull request, QWERTY keyboard, Richard Stallman, risk tolerance, Schrödinger's Cat, side project, software as a service, Steven Levy, systems thinking, web application, Y Combinator, Y2K

The development and physical views have a similar relationship. Figure 8-3 shows what this hypothetical system might look like in a development view. Figure 8-3: Development view, how the code is structured Code is organized into two classes: Documents and Tags. Each class has a set of methods reflecting a Create, Read, Update, and Delete (CRUD) structure. This system saves the document as soon as we’ve verified that it’s safe, so that if the parser fails, we don’t lose data. It tokenizes as it parses and creates tags after. The physical view might look more like Figure 8-4. Users access the system from browsers on their computers.


HBase: The Definitive Guide by Lars George

Alignment Problem, Amazon Web Services, bioinformatics, create, read, update, delete, Debian, distributed revision control, domain-specific language, en.wikipedia.org, fail fast, fault tolerance, Firefox, FOSDEM, functional programming, Google Earth, information security, Kickstarter, place-making, revision control, smart grid, sparse data, web application

Finally, it should be able to store the entire web crawl and work with MapReduce to build the entire search index in a timely manner. Being aware of the shortcomings of RDBMSes at scale (see Seek Versus Transfer for a discussion of one fundamental issue), the engineers approached this problem differently: forfeit relational features and use a simple API that has basic create, read, update, and delete (or CRUD) operations, plus a scan function to iterate over larger key ranges or entire tables. The culmination of these efforts was published in 2006 in a paper titled “Bigtable: A Distributed Storage System for Structured Data”, two excerpts from which follow: Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers.

* * * [49] The region servers use a multiversion concurrency control mechanism, implemented internally by the ReadWriteConsistencyControl (RWCC) class, to guarantee that readers can read without having to wait for writers. Writers do need to wait for other writers to complete, though, before they can continue. CRUD Operations The initial set of basic operations are often referred to as CRUD, which stands for create, read, update, and delete. HBase has a set of those and we will look into each of them subsequently. They are provided by the HTable class, and the remainder of this chapter will refer directly to the methods without specifically mentioning the containing class again. Most of the following operations are often seemingly self-explanatory, but the subtle details warrant a close look.


Mastering Structured Data on the Semantic Web: From HTML5 Microdata to Linked Open Data by Leslie Sikos

AGPL, Amazon Web Services, bioinformatics, business process, cloud computing, create, read, update, delete, Debian, en.wikipedia.org, fault tolerance, Firefox, Google Chrome, Google Earth, information retrieval, Infrastructure as a Service, Internet of things, linked data, machine readable, machine translation, natural language processing, openstreetmap, optical character recognition, platform as a service, search engine result page, semantic web, Silicon Valley, social graph, software as a service, SPARQL, text mining, Watson beat the top human players on Jeopardy!, web application, Wikidata, wikimedia commons, Wikivoyage

Accessed 2 April 2015. 143 Chapter 6 Graph Databases Graph models and algorithms are ubiquitous, due to their suitability for knowledge representation in e-commerce, social media networks, research, computer networks, electronics, as well as for maximum flow problems, route problems, and web searches. Graph databases are databases with Create, Read, Update, and Delete (CRUD) methods exposing a graph data model, such as property graphs (containing nodes and relationships), hypergraphs (a relationship can connect any number of nodes), RDF triples (subject-predicate-object), or quads (named graph-subject-predicate-object). Graph databases are usually designed for online transactional processing (OLTP) systems and optimized for transactional performance, integrity, and availability.


pages: 420 words: 79,867

Developing Backbone.js Applications by Addy Osmani

Airbnb, anti-pattern, business logic, create, read, update, delete, don't repeat yourself, Firefox, full text search, Google Chrome, Khan Academy, Kickstarter, loose coupling, MVC pattern, node package manager, pull request, Ruby on Rails, side project, single page application, web application

We are now ready to run our first server: node server.js If you open a browser on http://localhost:4711 you should see something like this: This is where we left off in Part 2, but we are now running on a server instead of directly from the files. Great job! We can now start defining routes (URLs) that the server should react to. This will be our REST API. Routes are defined by using app followed by one of the HTTP verbs get, put, post, and delete, which corresponds to Create, Read, Update and Delete. Let us go back to server.js and define a simple route: // Routes app.get( '/api', function( request, response ) { response.send( 'Library API is running' ); }); The get function takes a URL as the first parameter and a function as the second. The function will be called with request and response objects.


pages: 422 words: 86,414

Hands-On RESTful API Design Patterns and Best Practices by Harihara Subramanian

blockchain, business logic, business process, cloud computing, continuous integration, create, read, update, delete, cyber-physical system, data science, database schema, DevOps, disruptive innovation, domain-specific language, fault tolerance, information security, Infrastructure as a Service, Internet of things, inventory management, job automation, Kickstarter, knowledge worker, Kubernetes, loose coupling, Lyft, machine readable, microservices, MITM: man-in-the-middle, MVC pattern, Salesforce, self-driving car, semantic web, single page application, smart cities, smart contracts, software as a service, SQL injection, supply-chain management, web application, WebSocket

Google Maps and Locations, Apple iTunes, Google Books, UK police forces (https://data.police.uk/api/forces), sunrise and sunset timings (https://sunrise-sunset.org/api), and the British National Bibliography (http://bnb.data.bl.uk) are few examples of public APIs. The REST API examples that we have so far are more reading operations. However, in reality, the APIs can do a lot more, and we will show how well we can design RESTful APIs that can support create, read, update, and delete (CRUD) operations, pagination, filtering, sorting, searching, and much more as you read through this book. We encourage you to get to know various publicly available APIs, their purpose, response formats, and so on as it will help you to understand and follow the further discussions in this chapter.


Data and the City by Rob Kitchin,Tracey P. Lauriault,Gavin McArdle

A Declaration of the Independence of Cyberspace, algorithmic management, bike sharing, bitcoin, blockchain, Bretton Woods, Chelsea Manning, citizen journalism, Claude Shannon: information theory, clean water, cloud computing, complexity theory, conceptual framework, corporate governance, correlation does not imply causation, create, read, update, delete, crowdsourcing, cryptocurrency, data science, dematerialisation, digital divide, digital map, digital rights, distributed ledger, Evgeny Morozov, fault tolerance, fiat currency, Filter Bubble, floating exchange rates, folksonomy, functional programming, global value chain, Google Earth, Hacker News, hive mind, information security, Internet of things, Kickstarter, knowledge economy, Lewis Mumford, lifelogging, linked data, loose coupling, machine readable, new economy, New Urbanism, Nicholas Carr, nowcasting, open economy, openstreetmap, OSI model, packet switching, pattern recognition, performance metric, place-making, power law, quantum entanglement, RAND corporation, RFID, Richard Florida, ride hailing / ride sharing, semantic web, sentiment analysis, sharing economy, Silicon Valley, Skype, smart cities, Smart Cities: Big Data, Civic Hackers, and the Quest for a New Utopia, smart contracts, smart grid, smart meter, social graph, software studies, statistical model, tacit knowledge, TaskRabbit, technological determinism, technological solutionism, text mining, The Chicago School, The Death and Life of Great American Cities, the long tail, the market place, the medium is the message, the scientific method, Toyota Production System, urban planning, urban sprawl, web application

Its importance is likely to continue to grow as all technologies move towards an API orientation. Based on REST architectural design principles, only HTTP methods need to be used explicitly for different purposes (Fielding 2000). This basic REST design principle establishes a one-to-one mapping between create, read, update and delete (CRUD) operations and HTTP methods. According to this mapping: POST is used to create a resource on the server, GET is used to retrieve a resource, PUT is used to update or change the state of a resource, and DELETE used for removing a resource. RESTful services are easier to implement, maintain and utilize, but they do not have powerful and standard support for features like standard contract (or machine-readable service description) distributed transactions, composition and security, which are needed in most enterprise applications, and that is why Sharing and analysing data in smart cities 131 most enterprise applications implement Web Services (Daigneau 2011).


pages: 982 words: 221,145

Ajax: The Definitive Guide by Anthony T. Holdener

AltaVista, Amazon Web Services, business logic, business process, centre right, Citizen Lab, Colossal Cave Adventure, create, read, update, delete, database schema, David Heinemeier Hansson, en.wikipedia.org, Firefox, full text search, game design, general-purpose programming language, Guido van Rossum, information retrieval, loose coupling, machine readable, MVC pattern, Necker cube, p-value, Ruby on Rails, SimCity, slashdot, social bookmarking, sorting algorithm, SQL injection, Wayback Machine, web application

The book_authors table will contain ID and name fields, and the book_author_title_xref table will contain ID, title ID, and author ID fields: CREATE TABLE book_authors ( auth_id MEDIUMINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, auth_nm VARCHAR(60) NOT NULL, UNIQUE KEY _auth_key_1 (auth_nm) ); CREATE TABLE book_author_title_xref ( title_id BIGINT NOT NULL REFERENCES book_titles (title_id), auth_id MEDIUMINT NOT NULL REFERENCES book_authors (auth_id), UNIQUE KEY _auth_title_key_1 (title_id, auth_id) ); All that is left now is to create a table with the remaining columns that we will call book_titles: 50 | Chapter 3: Servers, Databases, and the Web CREATE TABLE book_titles ( title_id BIG_INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, title_dsc VARCHAR(100) NOT NULL, pub_dte VARCHAR(20) NULL, pub_id MEDIUMINT NOT NULL REFERENCES book_publishers (pub_id), isbn_10 VARCHAR(13) NOT NULL, isbn_13 VARCHAR(18) NOT NULL, num_pages SMALLINT NULL, orig_price FLOAT(2) NULL, type_id TINYINT NOT NULL REFERENCES book_type (type_id), cat_id TINYINT NOT NULL REFERENCES book_category (cat_id), acq_id TINYINT NOT NULL REFERENCES book_acquired (acq_id), UNIQUE KEY _title_key_1 (isdn_10, isdb_13), KEY _title_key_2 (title_dsc, pub_id, pub_dte) ); The hard part is done—creating a database that has good indexing and relational tables yet conserves space wherever possible is a tall order, and should really be considered an art. A database expert could do better, and for a larger project I recommend seeking design assistance, but for our purposes this will suffice. Now, we need to consider how to get functionality out of our database with just the basic functions of Create, Read, Update, and Delete (CRUD). You can create new records in tables with the INSERT statement, read them using the SELECT statement (become friends with this statement, as you will use it most often), update them using the UPDATE statement, and delete them using the DELETE statement. These four commands will accomplish everything necessary in an application.

Some of these books are: • Understanding MySQL Internals by Sasha Pachev (O’Reilly) • Programming SQL Server 2005 by Bill Hamilton (O’Reilly) • Optimizing Oracle Performance by Carl Millsap (O’Reilly) Instead of talking about optimizing the SQL server itself, I will concentrate on something I know more about—pulling data from the server. You can pull data from a SQL server in two ways: via inline queries and via stored procedures. And you can optimize both to make data return more quickly. Also, note that I am concentrating on bringing back data to the client, and not on the other create, read, update, and delete (CRUD) operations. This is because we can’t do much to make INSERT, UPDATE, or DELETE statements run much faster than they do naturally. Anything you can do you can find in books that specialize in SQL optimization, such as High Performance MySQL by Derek J. Balling and Jeremy Zawodny (O’Reilly).


pages: 378 words: 67,804

Learning Android by Marko Gargenta

business logic, create, read, update, delete, database schema, Firefox, loose coupling, slashdot, SQL injection, web application

It always refills the table with tweets from the past 24 hours, which are the only ones our users will care about. Four Major Operations The DbHelper class offers you a high-level interface that’s much simpler than SQL. The developers realized that most applications use databases for only four major operations, which go by the appealing acronym CRUD: create, read (query), update, and delete. To fulfill these requirements, DbHelper offers: insert() Inserts one or more rows into the database query() Requests rows matching the criteria you specify update() Replaces ones or more rows that match the criteria you specify delete() Deletes rows matching the criteria you specify Each of these methods has variants that enhance it with other functions.


pages: 739 words: 174,990

The TypeScript Workshop: A Practical Guide to Confident, Effective TypeScript Programming by Ben Grynhaus, Jordan Hudgens, Rayon Hunte, Matthew Thomas Morgan, Wekoslav Stefanovski

Ada Lovelace, Albert Einstein, business logic, Charles Babbage, create, read, update, delete, don't repeat yourself, Donald Knuth, fault tolerance, Firefox, full stack developer, functional programming, Google Chrome, Hacker News, higher-order functions, inventory management, Kickstarter, loose coupling, node package manager, performance metric, QR code, Ruby on Rails, SQL injection, type inference, web application, WebSocket

Once you've installed Postman, check its documentation (https://learning.postman.com/docs/getting-started/sending-the-first-request/) and get ready for the next exercise. Exercise 12.06: Implementing a RESTful API backed by sqlite In this exercise, you will create a REST API backed by sqlite. In this project, you will implement all CRUD (create, read, update, and delete) operations in the sqlite database and we will expose the corresponding REST verbs (POST, GET, PUT, and DELETE) from our web server: Note The code file for this exercise can also be found here: https://packt.link/rlX7G. To get started, clone the project from GitHub and change to the directory for this exercise.


pages: 834 words: 180,700

The Architecture of Open Source Applications by Amy Brown, Greg Wilson

8-hour work day, anti-pattern, bioinformatics, business logic, c2.com, cloud computing, cognitive load, collaborative editing, combinatorial explosion, computer vision, continuous integration, Conway's law, create, read, update, delete, David Heinemeier Hansson, Debian, domain-specific language, Donald Knuth, en.wikipedia.org, fault tolerance, finite state, Firefox, Free Software Foundation, friendly fire, functional programming, Guido van Rossum, Ken Thompson, linked data, load shedding, locality of reference, loose coupling, Mars Rover, MITM: man-in-the-middle, MVC pattern, One Laptop per Child (OLPC), peer-to-peer, Perl 6, premature optimization, recommendation engine, revision control, Ruby on Rails, side project, Skype, slashdot, social web, speech recognition, the scientific method, The Wisdom of Crowds, web application, WebSocket

The difference between Recno and Queue is that Queue supports record-level locking, at the cost of requiring fixed-length values. Recno supports variable-length objects, but like Btree and Hash, supports only page-level locking. We originally designed Berkeley DB such that the CRUD functionality (create, read, update and delete) was key-based and the primary interface for applications. We subsequently added cursors to support iteration. That ordering led to the confusing and wasteful case of largely duplicated code paths inside the library. Over time, this became unmaintainable and we converted all keyed operations to cursor operations (keyed operations now allocate a cached cursor, perform the operation, and return the cursor to the cursor pool).


pages: 1,409 words: 205,237

Architecting Modern Data Platforms: A Guide to Enterprise Hadoop at Scale by Jan Kunigk, Ian Buss, Paul Wilkinson, Lars George

Amazon Web Services, barriers to entry, bitcoin, business intelligence, business logic, business process, cloud computing, commoditize, computer vision, continuous integration, create, read, update, delete, data science, database schema, Debian, deep learning, DevOps, domain-specific language, fault tolerance, Firefox, FOSDEM, functional programming, Google Chrome, Induced demand, information security, Infrastructure as a Service, Internet of things, job automation, Kickstarter, Kubernetes, level 1 cache, loose coupling, microservices, natural language processing, Network effects, platform as a service, single source of truth, source of truth, statistical model, vertical integration, web application

Apache ZooKeeper is the resilient, distributed configuration service for the Hadoop ecosystem. Within ZooKeeper, configuration data is stored and accessed in a filesystem-like tree of nodes, called znodes, each of which can hold data and be the parent of zero or more child nodes. Clients open a connection to a single ZooKeeper server to create, read, update and delete the znodes. For resilience, ZooKeeper instances should be deployed on different servers as an ensemble. Since ZooKeeper operates on majority consensus, an odd number of servers is required to form a quorum. Although even numbers can be deployed, the extra server provides no extra resilience to the ensemble.


pages: 1,380 words: 190,710

Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems by Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield

air gap, anti-pattern, barriers to entry, bash_history, behavioural economics, business continuity plan, business logic, business process, Cass Sunstein, cloud computing, cognitive load, continuous integration, correlation does not imply causation, create, read, update, delete, cryptocurrency, cyber-physical system, database schema, Debian, defense in depth, DevOps, Edward Snowden, end-to-end encryption, exponential backoff, fault tolerance, fear of failure, general-purpose programming language, Google Chrome, if you see hoof prints, think horses—not zebras, information security, Internet of things, Kubernetes, load shedding, margin call, microservices, MITM: man-in-the-middle, NSO Group, nudge theory, operational security, performance metric, pull request, ransomware, reproducible builds, revision control, Richard Thaler, risk tolerance, self-driving car, single source of truth, Skype, slashdot, software as a service, source of truth, SQL injection, Stuxnet, the long tail, Turing test, undersea cable, uranium enrichment, Valgrind, web application, Y2K, zero day

When we talk about the API of a distributed system, we simply mean the sum of all the ways you can query or modify its internal state. API design has been well covered in computing literature;8 this chapter focuses on how you can design and safely maintain secure systems by exposing API endpoints with few well-defined primitives. For example, the input you evaluate might be CRUD (Create, Read, Update, and Delete) operations on a unique ID, rather than an API that accepts a programming language. In addition to the user-facing API, pay careful attention to the administrative API. The administrative API is equally important (arguably, more important) to the reliability and security of your application.