DOCSLIB.ORG

Application/Json Headers Content-Type: Application/Json

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Application/Json Headers Content-Type: Application/Json Documenting APIs with Swagger TC Camp Peter Gruenbaum Introduction } Covers } What is an API Definition? } YAML } Open API Specification } Writing Documentation } Generating Documentation } Alternatives to Swagger and the Open API Specification } Presentation and workbook at sdkbridge.com/downloads © 2018 SDK Bridge Peter Gruenbaum } PhD in Applied Physics from Stanford } Commercial Software Developer } Boeing, Microsoft, start-ups } C#, C++, Java, JavaScript, Objective-C } API Writer } Brought together writing and technology } Since 2003 } President of SDK Bridge } Teacher: Programming at middle, high school, and college © 2018 SDK Bridge API Definition } Swagger and the Open API Specification are ways to define an API } What is an API? } What can you do with an API definition? © 2018 SDK Bridge What are APIs? } Application Programming Interface } It defines how two pieces of software talk to each other } For this seminar, we are talking about Web APIs © 2018 SDK Bridge Web APIs API request API response Creative Commons Attribution 3.0. webdesignhot.com Creative Commons Attribution 3.0. Not a full web page ─ just the data! openclipart.org The API definition describes: • What requests are available • What the response looks like for each request © 2018 SDK Bridge REST } Swagger and the Open API Specification are designed for RESTful APIs } REST is a type of web API REpresentational State Transfer © 2018 SDK Bridge REST Requests and Responses Please send me the state of my feed API request API response I am transferring to you some data that represents the state of your feed © 2018 SDK Bridge How many public APIs are there? © 2018 SDK Bridge API Definition File } File describes all the things you can do with an API } Lists every request you can make } Tells you how to make that request } Tells you what the response will look like © 2018 SDK Bridge Why Create an API Definition? } Lets you design the API before implementing it } Helps with automated testing } Automatically create code in several languages } Can be used to automatically generate documentation } Documentation can be interactive © 2018 SDK Bridge Swagger } Historically, Swagger was a specification for how to create an API definition file } After a new version (Swagger 2.0), the specification became the Open API Specification (OAS) } Swagger is now a collection of tools that use the Open API Specification } Many people still refer to OAS as “Swagger” © 2018 SDK Bridge Open API Initiative } The Open API Initiative (OAI) is an organization created by a consortium of industry experts } Focused on creating, evolving, and promoting a vendor neutral description format. } It is in charge of the Open API Specification, but not in charge of any tools that use it } I will show you version 2.0, and talk about 3.0 © 2018 SDK Bridge Swagger Tools Swagger provides several tools: } Swagger Editor: Helps you write OAS files } Swagger CodeGen: Generates code in popular languages for using your API } Swagger UI: Generates documentation from OAS files } SwaggerHub: Hosted platform for designing and documenting APIs © 2018 SDK Bridge Documentation example placeholder } http://petstore.swagger.io/ © 2018 SDK Bridge YAML Open API Specification Format Documenting APIs with Swagger Open API Specification } You can use one of two data formats for OAS: } YAML } JSON } For this seminar, I’ll use YAML © 2018 SDK Bridge YAML } Stands forYAML Ain’t Markup Language } It’s not a Markup Language like HTML } Used for structured data instead of free-form content } Compared to JSON and XML, it minimizes characters } It's most often used for configuration files, rather than files passed over the web, like JSON © 2018 SDK Bridge Key/value pairs } Key/value pairs are indicated by a colon followed by a space date: 2017-08-06 firstName: Peter © 2018 SDK Bridge Levels } Levels are indicated by white space indenting } Cannot be a tab indent <name> <firstName>Peter</firstName> XML <lastName>Gruenbaum</lastName> </name> name: { name: JSON "firstName": "Peter" YAML firstName: Peter "lastName": "Gruenbaum" lastName: Gruenbaum } © 2018 SDK Bridge Types } Types are determined from context } Example: string part_no: A4786 description: Photoresistor price: 1.47 float quantity: 4 integer © 2018 SDK Bridge Quotes } In general, you don’t need quotes around strings } Exception: something that will be interpreted as a number or boolean float price: 11.47 version: "11.47" company: SDK Bridge string } Quotes can be either single ' or double " © 2018 SDK Bridge Lists } Use a dash to indicate a cart: list item - part_no: A4786 description: Photoresistor } You don’t need to price: 1.47 declare the list quantity: 4 - part_no: B3443 description: LED color: blue price: 0.29 quantity: 12 © 2018 SDK Bridge Multi-line strings } Because there are no quotation marks on strings, you need special characters for multiline strings } | means preserve lines and spaces } > means fold lines } There are variations: |-, |+, etc. speech: | speech: > Four score Four score and seven years ago and seven years ago Four score and seven years ago Four score and seven years ago © 2018 SDK Bridge Comments } Comments are denoted with the # } Everything after # is ignored # LED part_no: B3443 description: LED color: blue price: 0.29 # US Dollars quantity: 12 © 2018 SDK Bridge Schemas } Although not officially part of YAML, OAS uses references for schemas } Used for request and response bodies } Use $ref to indicate a reference } Typically put the schema in a definitions section © 2018 SDK Bridge Schema example schema: $ref: '#/definitions/user' ... definitions: user: required: - username - id properties: username: type: string id: type: integer format: int64 © 2018 SDK Bridge Exercise 1: YAML } Write some simple YAML } Follow along in exercise book } Electronic copy available at sdkbridge.com/downloads © 2018 SDK Bridge API Definition What’s in an API Definition file? Documenting APIs with Swagger What’s an API Definition File? } A file that describes everything you can do with an API } Note: “API” means a collection of related requests } Server location } How security is handled (i.e., authorization) } All the available requests in that API } All the different data you can send in a request } What data is returned } What HTTP status codes can be returned © 2018 SDK Bridge The Anatomy of a Request Method URL Query parameters POST http://api.example.com/user?source=ios&device=ipad Accept: application/json Headers Content-type: application/json { "name": "Peter Gruenbaum", "email": "[email protected]" Body } © 2018 SDK Bridge URL } Example request URL: https://api.muzicplayz.com/v3/playlist } Scheme } https } Host } api.muzicplayz.com } Base path } /v3 } Path } /playlist © 2018 SDK Bridge Method } The HTTP method describes what kind of action to take } GET, POST, PUT, DELETE, etc. © 2018 SDK Bridge Parameters } Example: } https://api.muzicplayz.com/v3/playlist/{playlist-id}?language=en } Path Parameters } {playlist-id} } Query Parameters } language © 2018 SDK Bridge Request Body } For some methods (POST, PUT, etc.) you can specify a request body, often in JSON } The body is treated as a parameter } You specify a schema for the request body © 2018 SDK Bridge Response Body } In REST, the response body can be anything, but is most often structured data, such as JSON } The response object has a schema to describe the structured data } You can have a separate response object for each HTTP status code returned © 2018 SDK Bridge Security } Security means authentication and authorization } Can be: } None } Basic Auth } API key } OAuth © 2018 SDK Bridge Documentation } Human-readable descriptions of elements } For generating documentation } Add a “description” section for: } The API } Each operation (path and method) } Each parameter } Each response element } Will go into detail in the next section © 2018 SDK Bridge Getting the information to create an OAS file } If you are asked to create an OAS file, how do you find the information? } Developers can provide rough documentation } Developers can provide sample requests and responses } Most common } You can figure it out from the code } Requires strong coding skills © 2018 SDK Bridge Open API Specification Basics Defining Simple Requests Documenting APIs with Swagger Open API Specification File } Choose an example and build a file } Company: example.com } Service for uploading and sharing photos } API base URL: } https://api.example.com/photo © 2018 SDK Bridge Example © 2018 SDK Bridge Adding a Request Let’s define requests for getting photo albums Requests will have: } URL endpoint } HTTP Method } Path parameters } Query parameters } Also (covered later): } Request body } Responses © 2018 SDK Bridge Example with query parameters GET https://api.example.com/photo/album?start=2017-09-01&end=2017-09-31 © 2018 SDK Bridge Example with path parameter GET https://api.example.com/photo/album/123456 © 2018 SDK Bridge Data types } The data type can have several values } Includes: } Boolean } integer } number } string } array © 2018 SDK Bridge Custom headers } Custom headers are treated as parameters } Standard headers (authorization, content format) are handled elsewhere © 2018 SDK Bridge Documentation } Documentation is added using the description key } I will talk about this later in the workshop © 2018 SDK Bridge Swagger Editor } Swagger provides an editor for Open API Specification files } Go to http://editor2.swagger.io © 2018 SDK Bridge Exercise 2: OAS Basics } Create an OAS file for a music system } The API
Load more

Recommended publications
  • Practical API Design: Confessions Practical API Design of a Java™ Framework Architect
    CYAN YELLOW MAGENTA BLACK PANTONE 123 C BOOKS FOR PROFESSIONALS BY PROFESSIONALS® THE EXPERT’S VOICE® IN JAVA™ TECHNOLOGY Companion eBook Available Practical API Design: Confessions API Design Practical of a Java™ Framework Architect Dear Reader, Maybe you’re standing in a bookstore, holding this book in your hand, and ask- ing yourself, “Should I buy it?” Here is your answer. If you’ve ever written code and handed it to others to let them compile their code against yours, then you’re ready to enter the API design world and this book will help you explore it. Practical However, this book doesn’t attempt to “teach API design in five easy lessons.” It cannot be read in “only three days!” If you’re looking for a quick handbook, this book is probably not for you. On the other hand, if you’re interested in a deeper knowledge of API design, in knowing not only the how, but also the why, let me introduce myself to you before you put this book back on the shelf. My name is Jaroslav Tulach and I am the founder and initial architect of the NetBeans™ project, which is not just a well-known IDE, but also the first modu- lar desktop application framework written in the Java™ language. This book is based on notes that I’ve collected over the last ten years, while designing and API Design maintaining NetBeans APIs and transferring this knowledge to the rest of our developers. It’s a journal from the heart of the NetBeans laboratory, describing our problems, our growing understanding of them, the solutions we’ve chosen, ™ and the conclusions we made after applying them.
    [Show full text]
  • Introduction to API Documentation Workbook July 28, 2018 Peter Gruenbaum
    Introduction to API Documentation Workbook July 28, 2018 Peter Gruenbaum Table of Contents Exercise 1: Markdown............................................................................................................ 3 Exercise 2: Create a JSON file ................................................................................................. 4 Exercise 3: Document JSON files............................................................................................. 7 Exercise 4: Making REST Requests ........................................................................................ 11 Exercise 5: Documenting Method and URL ........................................................................... 16 Exercise 6: Using Query Parameters ..................................................................................... 17 Exercise 7: Documenting Query Parameters ......................................................................... 19 Discounts for Online Classes ................................................................................................ 21 Schedule for July 28, 2018 8:30 Registration and Introduction 9:00 Markdown 9:30 Data Types and JSON 10:15 Documenting JSON 11:00 Break 11:15 Structured Data for Docs 11:30 REST: Methods 12:15 Lunch 12:45 REST: URLs 1:30 REST: Query parameters 2:15 Break 2:30 Tools and Next Steps 2:45 Q&A © 2018 SDK Bridge, all rights reserved 2 Exercise 1: Markdown Follow these steps: 1. Go to https://stackedit.io/ 2. Click on Start Writing at the top 3. Delete any text that currently
    [Show full text]
  • Backup Server Archive API Company
    REFERENCE MANUAL | PUBLIC SAP Adaptive Server Enterprise 16.0 SP03 Document Version: 1.0 – 2019-01-15 Reference Manual: Backup Server Archive API company. All rights reserved. All rights company. affiliate THE BEST RUN 2019 SAP SE or an SAP SE or an SAP SAP 2019 © Content 1 Overview.................................................................. 3 1.1 Syntax.....................................................................3 1.2 Byte Stream Archive Command Options.............................................4 2 Application Programming Interface..............................................5 3 API Routines............................................................... 8 3.1 syb_defineapi................................................................8 3.2 syb_queryapi................................................................9 3.3 set_params................................................................ 10 3.4 syb_open..................................................................10 3.5 syb_close..................................................................11 3.6 syb_read.................................................................. 12 3.7 syb_write..................................................................13 4 Error Messages.............................................................15 4.1 Localization................................................................ 15 4.2 Error and Informational Messages................................................ 15 5 Dynamically Loadable Library..................................................17
    [Show full text]
  • Technical Writer
    Technical writer A technical writer (also called a technical communicator) is a professional writer who designs, writes, creates, maintains, and updates technical documentation. This documentation includes online help, user guides, white papers, design specifications, system manuals, and other documents. Engineers, scientists, and other professionals may also produce technical writing, usually handing their work to a professional technical writer for proofreading, editing, and formatting. A technical writer produces technical documentation for technical, business, and consumer audiences. Contents 1 Skill set 2 Qualifications 3 Methodology 4 Environment 5 Career growth 6 See also 7 References 8 External links Skill set In addition to solid research, language, and writing skills, a technical writer may have skills in: Information design Information architecture Training material development Illustration Typography Technical writing may be on any subject that requires explanation to a particular audience. A technical writer is not usually a subject matter expert (SME), but possesses and applies expertise to interview SMEs and conduct research necessary to produce accurate, comprehensive documents. Companies, governments, and other institutions typically hire technical writers not for expertise in a particular subject, but for expertise in technical writing, i.e., their ability to gather information, analyze subject and audience and produce clear documentation. A good technical writer creates documentation that is accurate, complete, unambiguous, and as concise as possible. Technical writers create documentation in many forms: printed, web-based or other electronic documentation, training materials, and industrial film scripts. Qualifications Technical writers work under many job titles, including Technical Communicator, Information Developer, Data Development Engineer, and Technical Documentation Specialist. In the United Kingdom and some other countries, a technical writer is often called a technical author or knowledge author.
    [Show full text]
  • What Is Api Documentation 6
    SEPTEMBER 2014 THE MAGAZINE OF THE SOCIETY FOR TECHNICAL COMMUNICATION WHAT IS API DOCUMENTATION 6 HOW DO YOU BREAK INTO API DOCUMENTATION? 9 WHAT FACTORS CONTRIBUTE TO GOOD API DOCUMENTATION? 12 LESSONS LEARNED AS A NOVICE API WRITER 16 HOW TO WRITE HELPFUL CODE SAMPLES 19 HOW MUCH PROGRAMMING DO YOU NEED TO KNOW TO WRITE API DOCUMENTATION? 23 API DOCUMENTATION How Do You shutterstock.com/Kutlayev Dmitryshutterstock.com/Kutlayev Break into API Documentation? By MARY CONNOR | Member The Market Government APIs (data.gov, http://catalog.data.gov/ Large numbers of us broke into technical writing by dataset?res_format=api&_res_format_limit=0) documenting software that runs on personal computers. Open APIs (Wikipedia, http://en.wikipedia.org/wiki/ Over the years, we have watched sales of those machines List_of_open_APIs) and their software packages stagnate. The manuals and Just how successful these APIs are has everything to do help that we created grew gaunt under the relentless with how quickly and easily programmers can become pressure to do it faster, cheaper, and lighter. With the power users of these new interfaces, and so everything rise of support-written knowledge bases (think ZenDesk, to do with documentation and tutorials, and us! That’s www.zendesk.com/) and community-generated content, the good news: the job market for programmer writers many wondered if conventional documentation jobs were has become habañero hot. Since I’ve put full-time API destined to fade. documentation experience on my profile, I’ve started Now we’re witnessing dizzying growth in high tech, receiving an eye-popping stream of unsolicited invitations driven by the shift to ubiquitous computing through for positions with tech companies that are everyday names mobile devices and by distributed, cloud-based storage to the wired crowd.
    [Show full text]
  • The Dart Programming Language This Page Intentionally Left Blank the Dart Programming Language
    The Dart Programming Language This page intentionally left blank The Dart Programming Language Gilad Bracha Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City Sao Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, train- ing goals, marketing focus, or branding interests), please contact our corporate sales department at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the United States, please contact [email protected]. Visit us on the Web: informit.com/aw Library of Congress Control Number: 2015953614 Copyright c 2016 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copy- right, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photo- copying, recording, or likewise.
    [Show full text]
  • Application Programming Interface
    Application programming interface “API” redirects here. For other uses, see API (disam- nent. This specification is presented in a human read- biguation). able format in paper books or in electronic formats like For the MediaWiki (the software used by Wikipedia) eBooks or as man pages. For example, the math API on API, see mw:API Unix systems is a specification on how to use the math- ematical functions included in the math library. Among In computer programming, an application program- these functions there is a function, named sqrt(), that can be used to compute the square root of a given number. ming interface (API) is a set of routines, protocols, and tools for building software applications. An API The Unix command man 3 sqrt presents the signature of expresses a software component in terms of its opera- the function sqrt in the form: tions, inputs, outputs, and underlying types. An API de- SYNOPSIS #include <math.h> double sqrt(double X); fines functionalities that are independent of their respec- float sqrtf(float X); DESCRIPTION sqrt computes the tive implementations, which allows definitions and im- positive square root of the argument. ... RETURNS plementations to vary without compromising the inter- On success, the square root is returned. If X is real and face. A good API makes it easier to develop a program positive... by providing all the building blocks. A programmer then puts the blocks together. This description means that sqrt() function returns the In addition to accessing databases or computer hardware, square root of a positive floating point number (single or such as hard disk drives or video cards, an API can ease double precision), as another floating point number.
    [Show full text]
  • Bradford Harrison's Resume
    Bradford Thomas Harrison 902 N. Spruce St. Gunnison, Colorado 81230 970-596-8073 [email protected] 9/2015 – Present: Self Employed, Gunnison, CO Developer and Founder, Newsflanks.com. Develop and maintain news Website visited by news seekers who want to see both sides (flanks) of a news story or trending issue. Technologies used: MongoDB, Express, Bootstrap, Nunjucks and Node.js on a Linux server (linode.com). Support “mobile first” by leveraging browser standards (HTML, JavaScript, CSS) and Node.js functionality instead of creating apps that get installed. Use Adobe and Microsoft tools mostly, including Photoshop, Illustrator, Visual Studio, Flash and Visio. Source code hosted at http://github.com/bradfordharrison. 1/2013 – 8/2015: Vast Broadband, Sioux Falls, SD Network Operations Center (NOC) Tech. Monitored and performed troubleshooting on Vast’s Internet, video and phone networks. Triaged cases from the call center, declaring outages or escalating as necessary. Wrote technical documentation for the NOC. Participated in 24x7 on-call schedule. Dispatched cable techs to repair residential and commercial network problems in the field. Vast spun off from Wide Open West (WOW!) in 2014, creating the need for a separate Vast NOC. 2/2006 – 10/2012: Siriusware Inc., Gunnison, CO QA and Documentation Manager. Responsible for tracking release development and ensuring adequate testing before deployment. Managed four testers and a technical writer. Developed more than 10,000 pages of technical documentation as HTML (WebWorks Help) and PDF. Implemented and maintained knowledge database (Google Mini). Member of the after-hours emergency technical support team. Siriusware was purchased by Accesso in 2013. 10/2000 – 9/2005: Adobe Systems Corp., San Jose, CA Sr.
    [Show full text]
  • API Specifications FP7-ICT-2009-5 257103
    Deliverable D3.2 FP7-ICT-2009-5 257103 June 2011 D3.2: webinos phase I device, network, and server-side API specifications FP7-ICT-2009-5 257103 D3.2: webinos phase I device, network, and server-side API specifications page: 2 of 396 Project Number : FP7-ICT-2009-5 257103 Project Title : Secure WebOS Application Delivery Environment (webinos) Deliverable Type : Public Deliverable Number : D 3.2 Contractual Delivery Date : June, 30th, 2011 Actual Date of Delivery : June, 30th, 2011 Title of Deliverable : webinos phase I device, network, and server-side API specifications Contributing Work Package : WP 3 Nature of Deliverable : Report Editor : SonyEricsson Authors : Fraunhofer FOKUS, Deutsche Telekom, ERCIM, Telecom Italia, TNO, BMW F+T, SonyEricsson., ISMB, Document History Version Date Author (Partner) Remarks 0.9 01/07/2011 SonyEricsson Initial version created from Wiki 1.0 α 04/07/2011 Fraunhofer FOKUS Updated, Word-formatted version This work is partially funded by webinos, an EU-funded project under the EU FP7 ICT Programme, No 257103. FP7-ICT-2009-5 257103 page: 3 of 396 D3.2: webinos phase I device, network, and server-side API specifications Abstract This deliverable covers the APIs to be implemented by a webinos device. According to the use cases and requirements defined in WP2 and the common components introduced in task 3.1, task 3.2 has defined a set of application programming interface specifications (APIs) to make the desired functionalities available to webinos applications. Due to earlier or ongoing standardization and implementation activities, e.g. within W3C and WAC, some needed APIs are already specified and available in modern browsers.
    [Show full text]
  • How to Write Doc Comments for the Javadoc Tool
    5.6.2018 How to Write Doc Comments for the Javadoc Tool Menu Sign In Country/Region Call Oracle Technology Network / Java / Java SE / Documentation Overview Java SE Downloads Java EE Documentation Community Java ME Technologies Java SE Advanced & Suite Training Java Embedded How to Write Doc Comments for the Javadoc Tool Javadoc Home Page Java DB Web Tier This document describes the style guide, tag and image conventions we use in documentation comments for Java programs written at Java Software, Oracle. It does not rehash related material covered elsewhere: Java Card For reference material on Javadoc tags, see the Javadoc reference pages. Java TV For the required semantic content of documentation comments, see Requirements for Writing Java API Specifications. New to Java Contents Introduction Community Principles Java Magazine Terminology Source Files Writing Doc Comments Format of a Doc Comment Doc Comment Checking Tool Descriptions A Style Guide Tag Conventions ( @tag) Documenting Default Constructors Documenting Exceptions with @throws Tag Package-Level Comments Documenting Anonymous Inner Classes Including Images Examples of Doc Comments Troubleshooting Curly Quotes (Microsoft Word) Introduction Principles At Java Software, we have several guidelines that might make our documentation comments different than those of third party developers. Our documentation comments define the official Java Platform API Specification. To this end, our target audience is those who write Java compatibility tests, or conform or re-implement the Java platform, in addition to developers. We spend time and effort focused on specifying boundary conditions, argument ranges and corner cases rather than defining common programming terms, writing conceptual overviews, and including examples for developers.
    [Show full text]
  • 2015 Technical Communication Summit Proceedings
    Society for Technical Communication Summit Proceedings 21–24 June 2015 Columbus, Ohio #STC15 www.stc.org summit.stc.org1 Notice The papers published in these Proceedings were reproduced from originals furnished by the authors. The opinions expressed and integrity of the informa- tion are the responsibility of the authors and not the Society for Technical Communication (STC). STC grants permission to educators and academic libraries to distribute articles from these Proceedings for classroom purposes. There is no charge to these institutions provided they give credit to the author, the Proceedings, and STC. All others must request permission. All product and company names herein are the property of their respective owners. © 2015 Society for Technical Communication Contact Information Society for Technical Communication 9401 Lee Highway Suite 300 Fairfax, VA 22031 +1.703.522.4114 +1.703.522.2075 (fax) www.stc.org Colophon This publication was produced using Adobe InDesign CS6. The heading typefaces used are Helvetica, Helvetica Condensed, and Helvetica Ultra Condensed by Linotype and licensed through Adobe. The text is set in Georgia, which is licensed through Microsoft. This Proceedings publication was com- piled and designed by Michael Opsteegh. 2015 Technical Communication Summit Committee The Society for Technical Communication’s 62nd Annual Conference focuses on important trends in our profession. This publication contains papers submitted in support of the 2015 Summit conference sessions. This year’s conference is the result of the
    [Show full text]
  • Sustainable Technologies for Mobile Applications
    Sustainable Technologies for Mobile Applications Approved: ____________________________________________ Date: _________________ Prof. Dr. Christoph Wentzel - Committee Chair Approved: ____________________________________________ Date: _________________ Prof. Qi Yang, Ph.D. - Committee Member Approved: ____________________________________________ Date: _________________ Prof. Dr. Bernhard Kreling - Committee Member Sustainable Technologies for Mobile Applications A Thesis presented to the Graduate Faculties University of Wisconsin Platteville (UWP) and University of Applied Sciences Darmstadt (h_da) In Partial Fulfillment of the Requirement for the Degree Master of Science By Simon Heckmann Committee Chair: Prof. Dr. Christoph Wentzel (h_da) Committee Member: Prof. Dr. Bernhard Kreling (h_da) Committee Member: Prof. Qi Yang, Ph.D. (UWP) Start date: 02/16/2011 End date: 08/16/2011 Statement of Authorship Statement of Authorship I hereby declare that this thesis is written on my own solely by using the sources quoted in the thesis body. All contents (including text, figures, and tables), which are taken from sources, both verbally and in terms of meanings, are clearly marked and referenced. The thesis has not been previously submitted to any other examination board, neither in this nor in a similar form. ___________________________________ Simon Heckmann i Acknowledgments Acknowledgments First of all I would like to thank my advising professors, Dr. Wentzel, Dr. Yang and Dr. Kreling for helping me with this thesis. The great discussions about my ideas, results and findings helped me a lot during the entire creation process of this document. Secondly, I owe special thanks to my supervisors and colleges at Merck for their great sug- gestions and support. Especially, I would like to thank Dr. Michaela Bühler and Matthias Feldmann for their professional guidance and continuous motivation to tackle the challenges of this thesis.
    [Show full text]