เรากำลังอัปเดต Data API ให้สอดคล้องกับวิธีที่ YouTube นับยอดดูสำหรับ Shorts
ดูข้อมูลเพิ่มเติม
เปลี่ยนจาก ClientLogin เป็น OAuth 2.0
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Ikai Lan, YouTube Developer Relations – June 2013
YouTube API ใช้ OAuth 2.0 เพื่อให้สิทธิ์คำขอของผู้ใช้ เราได้รับคำถามบ่อยครั้งว่าเราจะเพิ่มการรองรับการตรวจสอบสิทธิ์ ClientLogin หรือบริการที่คล้ายกันใน YouTube API ในอนาคตหรือไม่ อย่างไรก็ตาม เราได้เลิกใช้งาน ClientLogin อย่างเป็นทางการแล้วเมื่อวันที่ 20 เมษายน 2012 และไม่มีแผนที่จะเพิ่มกลไกดังกล่าว
มีเหตุผลหลายประการที่เราเชื่อว่าการรองรับขั้นตอนการให้สิทธิ์ OAuth 2.0 ที่หลากหลายจะดีกว่า ClientLogin สำหรับผู้ใช้ YouTube ขั้นตอนเหล่านี้รองรับ Use Case สําหรับแอปพลิเคชันในเดสก์ท็อป แอปพลิเคชันบนเว็บเท่านั้น แอปพลิเคชันในอุปกรณ์เคลื่อนที่แบบดั้งเดิม และแม้แต่แอปพลิเคชันที่ทํางานบนอุปกรณ์อย่างโทรทัศน์ที่ไม่มีกลไกการป้อนข้อมูลที่ซับซ้อน ซึ่งเป็นสิ่งที่ทําได้ยากโดยใช้ ClientLogin นอกจากนี้ เราพบว่า ClientLogin ทำให้นักพัฒนาแอปจำนวนมากปวดหัวมากขึ้นหลังการเปิดตัว ซึ่งเราได้อธิบายบางส่วนไว้ในบล็อกโพสต์ ClientLogin #FAIL
การใช้ OAuth 2.0 สําหรับสคริปต์แบบสแตนด์อโลนฝั่งเซิร์ฟเวอร์
นักพัฒนาซอฟต์แวร์จํานวนมากใช้ ClientLogin เพื่อให้สิทธิ์สคริปต์บรรทัดคําสั่งที่ทํางานบนเซิร์ฟเวอร์โดยไม่มีเบราว์เซอร์ เมื่อใช้ OAuth 2.0 จะต้องมีการใช้เบราว์เซอร์เกือบทุกครั้ง ยกเว้นในกรณีที่คุณทํางานในแอปพลิเคชัน Android ที่ใช้ Google Play Services เพื่อดึงข้อมูลโทเค็นผ่าน GoogleAuthUtil.
ในขั้นตอนการดำเนินการบนเว็บเท่านั้น เว็บไซต์ที่ต้องการเรียก API ที่ตรวจสอบสิทธิ์ในนามของผู้ใช้ต้องเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าการตรวจสอบสิทธิ์ google.com ซึ่งอธิบายสิ่งที่แอปพลิเคชันพยายามเข้าถึง จากนั้นเว็บแอปพลิเคชันจะได้รับโทเค็น ซึ่งจะใช้เพื่อเรียก API จากนั้นผู้ใช้จะเพิกถอนสิทธิ์เข้าถึงของแอปพลิเคชันได้ทุกเมื่อโดยใช้หน้า connected apps and sites
ตัวอย่างโค้ด Python แสดงวิธีที่สคริปต์บรรทัดคำสั่งสามารถเปิดเบราว์เซอร์และเรียก API จากหน้าต่างเทอร์มินัล สร้างเซิร์ฟเวอร์ในเครื่องเพื่อรอรับโค้ดหลังจากการเปลี่ยนเส้นทางการให้สิทธิ์ และบันทึกโทเค็นโดยอัตโนมัติสำหรับการเรียก API ในอนาคต วิดีโอที่แสดงวิธีการใช้งานมีดังนี้
โทเค็นที่ใช้คือสตริง ASCII หากเป็นโทเค็น offline โทเค็นดังกล่าวจะย้ายได้ เมื่อใช้โทเค็นที่ดึงข้อมูลมา คุณจะเรียกใช้สคริปต์บนเดสก์ท็อป จากนั้นคัดลอกและใช้โค้ดบนเซิร์ฟเวอร์ระยะไกลได้โดยไม่ต้องใช้ GUI ในกรณีที่โค้ดสร้างอินสแตนซ์ไคลเอ็นต์ OAuth 2.0 ด้วยรหัสไคลเอ็นต์และข้อมูลลับเดียวกัน นอกจาก Python แล้ว ไลบรารีของไคลเอ็นต์ Google API สำหรับภาษาโปรแกรมอื่นๆ ยังมีเมธอดตัวช่วยในการจัดการโทเค็นด้วย ซึ่งสามารถแชร์ระหว่างไคลเอ็นต์และนำไปใช้ในไลบรารี HTTP ระดับล่างได้โดยตรงในส่วนหัวของไคลเอ็นต์หรือใช้เป็นพารามิเตอร์ URL
ตัวอย่างสคริปต์ฝั่งเซิร์ฟเวอร์ที่ใช้โทเค็นออฟไลน์มีดังนี้
- เดมอนที่ตรวจสอบไดเรกทอรีเพื่อหาวิดีโอใหม่ที่จะอัปโหลดไปยัง YouTube โดยอัตโนมัติ
- งาน Cron ที่อัปเดตเพลย์ลิสต์ทุกวันด้วยเนื้อหาใหม่
- สคริปต์ที่ตรวจสอบข้อมูลวิดีโอผ่าน YouTube Analytics API และแจ้งผู้จัดการช่องเมื่อเกิดเหตุการณ์บางอย่างขึ้น เช่น เวลาในการรับชมรวมเกินขีดจำกัด โปรดทราบว่าในกรณีนี้ OAuth 2.0 เป็นวิธีการให้สิทธิ์เพียงวิธีเดียวที่รองรับ เนื่องจาก Analytics API ไม่รองรับ ClientLogin
ส่วนโทเค็นการเข้าถึงที่มีอายุการใช้งานยาวนานมีรายละเอียดเพิ่มเติมเกี่ยวกับวิธีสร้างโทเค็นออฟไลน์ที่ใช้กับกระบวนการฝั่งเซิร์ฟเวอร์ได้
แนวทางปฏิบัติแนะนำเกี่ยวกับรหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์
รหัสใดก็ตามที่ใช้รหัสไคลเอ็นต์และคู่คีย์ลับเดียวกันจะใช้โทเค็นการเข้าถึงเดียวกันได้ คุณควรจำกัดการเข้าถึงรหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์ไว้เฉพาะโค้ดที่ทำงานบนเครื่องและอุปกรณ์ภายในองค์กร
อย่าใส่รหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์ไว้ในโค้ดของแอปพลิเคชันบนอุปกรณ์เคลื่อนที่แบบเนทีฟ นักพัฒนาแอปทุกรายที่ดำเนินการตรวจสอบสิทธิ์ OAuth 2.0 จากอุปกรณ์เคลื่อนที่ควรใช้รหัสไคลเอ็นต์ "แอปพลิเคชันที่ติดตั้ง" ซึ่งจะขอข้อมูลเพิ่มเติมเพื่อยืนยันว่าคำขอดังกล่าวมาจากแอปพลิเคชันที่ทีมของคุณเผยแพร่เท่านั้น
ในอุปกรณ์ Android ระบบจะระบุแอปพลิเคชันของคุณโดยใช้ชื่อแพ็กเกจและแฮชใบรับรองการรับรองรวมกันแทนการใช้รหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์ อุปกรณ์ iOS จะใช้รหัสกลุ่มและรหัส App Store ดูเอกสารประกอบอย่างเป็นทางการเกี่ยวกับการดึงข้อมูลนี้ได้ในหน้าความช่วยเหลือของ Google API Console
บัญชีบริการใช้กับ YouTube API ไม่ได้
บัญชีบริการใช้ไม่ได้กับการเรียกใช้ YouTube Data API เนื่องจากบัญชีบริการต้องมีช่อง YouTube ที่เชื่อมโยง และคุณจะเชื่อมโยงช่องใหม่หรือช่องที่มีอยู่กับบัญชีบริการไม่ได้ หากคุณใช้บัญชีบริการเพื่อเรียก YouTube Data API เซิร์ฟเวอร์ API จะแสดงข้อผิดพลาดโดยตั้งค่าประเภทข้อผิดพลาดเป็น unauthorized และตั้งค่าเหตุผลเป็น youtubeSignupRequired
สิทธิ์เข้าถึง YouTube API แบบออฟไลน์/แบบถาวร
OAuth 2.0 มีโทเค็นที่มีอายุสั้นและโทเค็นที่มีอายุยาว สําหรับการดำเนินการแบบครั้งเดียว โทเค็นการเข้าถึงที่มีอายุการใช้งานสั้นๆ คือตัวเลือกที่ดีที่สุด โทเค็นเหล่านี้จะหมดอายุไม่นานหลังจากที่ได้รับ สำหรับงานที่ทำงานต่อเนื่องเป็นเวลานาน คุณอาจต้องพิจารณารับโทเค็นการรีเฟรช ซึ่งใช้ดึงข้อมูลโทเค็นการเข้าถึงที่มีอายุสั้น
โปรดใช้ขั้นตอน "แอปพลิเคชันที่ติดตั้ง" เมื่อสร้างรหัสไคลเอ็นต์ และเลือก Other สำหรับค่า "ประเภทแอปพลิเคชันที่ติดตั้ง" เพื่อให้แอปพลิเคชันได้รับโทเค็นรีเฟรชที่มีอายุการใช้งานยาวนาน ไม่ใช่โทเค็นการเข้าถึงที่มีอายุการใช้งานสั้น
เราขอแนะนำให้ใช้เวิร์กโฟลว์ "แอปพลิเคชันที่ติดตั้ง" สำหรับกรณีการใช้งานนี้ หากต้องการเข้าถึง YouTube API ในเว็บแอปพลิเคชันในระยะยาว คุณสามารถดึงข้อมูลได้โดยตั้งค่าพารามิเตอร์ access_type เป็น offline และพารามิเตอร์ approval_prompt เป็น force ในคำขอการให้สิทธิ์เริ่มต้นหรือการกําหนดค่าไคลเอ็นต์ ไลบรารีของไคลเอ็นต์บางรายการจะจัดการการดึงข้อมูลและการรีเฟรชโทเค็นการเข้าถึง หากสนใจเขียนรหัสการให้สิทธิ์ที่กําหนดเอง เราเผยแพร่บล็อกโพสต์ในบล็อก Google Code ไว้ให้คุณใช้เป็นพื้นฐานสําหรับเขียนโค้ด
การใช้ OAuth 2.0 กับโทรศัพท์ แท็บเล็ต และอุปกรณ์อื่นๆ
เมื่อเขียนแอปพลิเคชัน Android นักพัฒนาแอปสามารถใช้ Google Play services เพื่อจัดการรายละเอียดการให้สิทธิ์ บริการ Google Play มีขั้นตอนการให้สิทธิ์มาตรฐานสำหรับ Google API ทั้งหมด รวมถึง API สำหรับแพลตฟอร์ม YouTube แนวทางนี้จะมอบประสบการณ์การใช้งานที่เหนือกว่ามากให้แก่ผู้ใช้แอปพลิเคชัน Android ของคุณเมื่อเทียบกับการตรวจสอบสิทธิ์ที่กำหนดเองโดยใช้ ClientLogin
ในอุปกรณ์ iOS Google มี 2 ตัวเลือกดังนี้
สำหรับอุปกรณ์ที่มีไว้เพื่อทำหน้าที่เป็น "หน้าจอที่ 2" หรืออุปกรณ์อย่างทีวีที่ไม่มีกลไกอินพุตที่ใช้งานง่าย เราขอแนะนำให้ใช้ OAuth 2.0 สำหรับอุปกรณ์ OAuth 2.0 สำหรับอุปกรณ์จะทำงานโดยการแสดงรหัสที่ไม่ซ้ำกันสำหรับผู้ใช้เมื่อจำเป็นต้องมีคำขอการให้สิทธิ์ เมื่อถึงขั้นตอนนี้ ระบบจะขอให้ผู้ใช้ไปที่ http://google.com/device ในอุปกรณ์เครื่องอื่น เช่น แล็ปท็อปหรือโทรศัพท์ แล้วป้อนรหัสที่ไม่ซ้ำกัน แอปพลิเคชันจะแสดงหน้าจอที่มีลักษณะดังต่อไปนี้
ขณะที่ผู้ใช้ป้อนรหัสในอุปกรณ์เครื่องอื่น แอปพลิเคชันจะตรวจสอบเป็นระยะๆ เพื่อดูว่าป้อนรหัสแล้วหรือยัง เมื่อได้รับแล้ว ระบบจะดึงข้อมูลโทเค็นสําหรับการเรียก API หากต้องการดูการทํางานของฟีเจอร์นี้ ให้ดูการสาธิต ซึ่งสามารถทํางานบนอุปกรณ์ที่เปิดใช้เว็บได้ API นี้ใช้ได้กับทุกแพลตฟอร์ม จึงมีประโยชน์สําหรับอุปกรณ์ที่ไม่มีความสามารถในการแสดงผลเว็บ เราได้โพสต์โค้ดตัวอย่างใน Python สำหรับเดโมไว้ให้ใช้เป็นข้อมูลอ้างอิง
สรุป
การให้สิทธิ์ OAuth 2.0 มอบความยืดหยุ่นให้แก่นักพัฒนาแอปที่ต้องให้สิทธิ์ YouTube นักพัฒนาซอฟต์แวร์ที่คุ้นเคยกับ ClientLogin อาจพบว่าการตั้งค่าแอปพลิเคชันเพื่อใช้ OAuth 2.0 นั้นเริ่มต้นได้ยากกว่าเล็กน้อย แต่เมื่อพอร์ตแล้ว แอปพลิเคชัน OAuth 2.0 จะมีความยืดหยุ่น ปลอดภัย และใช้งานได้ง่ายขึ้นสำหรับผู้ใช้ปลายทางในแพลตฟอร์มต่างๆ
หากมีคำถามเพิ่มเติมเกี่ยวกับ OAuth 2.0 หรือตัวอย่างในบทความนี้ โปรดถามโดยใช้แท็ก youtube-api ใน StackOverflow
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-02-06 UTC
[null,null,["อัปเดตล่าสุด 2025-02-06 UTC"],[[["\u003cp\u003eYouTube APIs use OAuth 2.0 for user request authorization, and ClientLogin has been officially deprecated with no plans for future support.\u003c/p\u003e\n"],["\u003cp\u003eOAuth 2.0 offers broader support for various application types, including desktop, web, mobile, and devices with limited input capabilities, providing superior flexibility compared to ClientLogin.\u003c/p\u003e\n"],["\u003cp\u003eServer-side scripts can leverage OAuth 2.0 through offline tokens, allowing for portability and persistent access across different environments without a constant need for browser interaction.\u003c/p\u003e\n"],["\u003cp\u003eFor mobile applications, it is crucial to avoid including client ID and secret in native code, instead using mechanisms like package names and certificate hashes for Android, or bundle and app store IDs for iOS.\u003c/p\u003e\n"],["\u003cp\u003eService accounts will not work with YouTube APIs and will return an error as they cannot be connected to YouTube channels.\u003c/p\u003e\n"]]],["YouTube APIs use OAuth 2.0 for authorization, having deprecated ClientLogin. OAuth 2.0 supports various application types, including server-side scripts, web apps, and mobile apps. Server-side scripts use \"offline\" tokens for long-lived access, enabling tasks like automated video uploads and playlist updates. Client ID and secrets should be restricted to internal code. Mobile apps use unique identifiers, while \"second screen\" devices use a code-based authorization. OAuth 2.0 offers superior security and flexibility across platforms.\n"],null,["# Move from ClientLogin to OAuth 2.0\n\n*Ikai Lan, YouTube Developer Relations -- June 2013*\nYouTube APIs use [OAuth 2.0](https://developers.google.com/youtube/v3/guides/authentication) to authorize user requests. We are frequently asked whether we will add support for ClientLogin authentication or something similar in YouTube APIs going forward. However, we [officially deprecated ClientLogin as of April 20, 2012](https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin), and there are no plans to add such a mechanism.\n\nThere are numerous reasons why we believe supporting various flows of OAuth 2.0 authorization is better for YouTube users than ClientLogin. These flows support use cases for desktop applications, web-only applications, native mobile applications, and even applications that run on devices like televisions that don't have sophisticated input mechanisms, something which is difficult to do using ClientLogin. Also, we've found that ClientLogin causes more headaches post-launch for many developers, some of which we describe in our blog post, [ClientLogin #FAIL](http://apiblog.youtube.com/2011/03/clientlogin-fail.html).\n\nUsing OAuth 2.0 for server-side, standalone scripts\n---------------------------------------------------\n\nMany developers use ClientLogin to authorize command-line scripts that run on servers without a browser. With OAuth 2.0, there's almost always going to be a browser involved -- the exception being when you're working on an Android application that uses Google Play Services to fetch tokens via [GoogleAuthUtil.](http://developer.android.com/reference/com/google/android/gms/auth/GoogleAuthUtil.html)\n\nIn a [web-only flow](https://developers.google.com/accounts/docs/OAuth2WebServer), a website that wants to make authenticated API calls on behalf of a user must redirect the user to a google.com authentication page that explains what the application is trying to access. The web application then receives a token, which it uses to make API calls. The user can then revoke the application's access at any time using the [connected apps and sites](https://accounts.google.com/IssuedAuthSubTokens) page.\n\nOur [Python code samples](https://developers.google.com/youtube/v3/code_samples/python) demonstrate how command-line scripts can launch a browser and make API calls from a terminal window, create a local server to listen for the code after the authorization redirect, and automatically save a token for future API calls. A video of this in action is below:\n\nThe token used is an ASCII string. If it is an `offline` token, it is *portable* . Using the retrieved token, you will be able to run the script on your desktop, then copy and use the code on a remote server without a GUI, provided that code instantiates an OAuth 2.0 client with the same client ID and secret. In addition to Python, the [Google API client libraries](https://developers.google.com/discovery/libraries) for other programming languages also provide helper methods for managing tokens, which can be shared between clients and even used in lower-level HTTP libraries directly [in a client header or as a URL parameter](https://developers.google.com/accounts/docs/OAuth2UserAgent#callinganapi).\n\nSome examples of server-side scripts that use offline tokens:\n\n- A daemon that monitors a directory for new videos to automatically upload to YouTube\n- A cron job that that updates playlists daily with new content\n- A script that monitors video data via the [YouTube Analytics API](https://developers.google.com/youtube/analytics/) and notifies channel managers when certain events take place, such as aggregate watch time exceeding a limit. Note that in this case, OAuth 2.0 is the only supported authorization method because the Analytics API does not support ClientLogin.\n\nThe section on [long-lived access tokens](#offline_access) provides more detail about how to generate the offline tokens that can be used for server side processes.\n\nClient ID and client secret best practices\n------------------------------------------\n\nAny code that shares the same client ID and secret pair can use the same access tokens. It's best to restrict access to client ID and client secrets to code that runs on machines and devices within your organization.\n\nDo not include your client ID and client secret as part of your native mobile applications code. All developers doing OAuth 2.0 authentication from a mobile device should make use of the \"Installed application\" client ID, which asks for additional information to verify that the request is coming only from an application released by your team.\n\nOn Android devices, instead of using a client ID and client secret, your application is identified using a combination of the package name and a signing certificate hash. On iOS devices, the bundle ID and the app store ID are used. The official documentation on retrieving this information can be found on the [Google API Console help page](https://developers.google.com/console/help/#installed_applications).\n\nService Accounts do not work with the YouTube API\n-------------------------------------------------\n\nService accounts do not work for YouTube Data API calls because service accounts require an associated YouTube channel, and you cannot associate new or existing channels with service accounts. If you use a service account to call the YouTube Data API, the API server [returns an error](https://developers.google.com/youtube/v3/docs/errors#youtube.api.RequestContextError-unauthorized-youtubeSignupRequired) with the error type set to `unauthorized` and the reason set to `youtubeSignupRequired`.\n\nOffline/long-lived access to the YouTube API\n--------------------------------------------\n\nOAuth 2.0 has short-lived tokens and long-lived tokens. For one-off operations, short-lived [access tokens](https://tools.ietf.org/html/rfc6749#section-1.4) are the best option. These tokens expire shortly after they are granted. For long running jobs, you may want to look into acquiring a [refresh token](https://developers.google.com/youtube/v3/guides/authentication#OAuth2_Refreshing_a_Token), which is used to fetch short-lived access tokens.\n\nTo ensure that your application receives a long-lived refresh token and not a short-lived access token, use the \"Installed Application\" flow when creating a client ID, and select `Other` for the \"Installed application type\" value:\n\nIt's recommended that you use the \"Installed application\" flow for this use case. If you need long-lived access to the YouTube API in a web application, you can retrieve one by setting the `access_type` parameter to `offline` and the `approval_prompt` parameter to `force` in the [initial authorization request or your client configuration](https://developers.google.com/accounts/docs/OAuth2WebServer#offline). Some client libraries will manage fetching and refreshing access tokens. If you are interested in writing your own custom authorization code, we published a [blog post on the Google Code blog](http://googlecode.blogspot.com/2011/10/upcoming-changes-to-oauth-20-endpoint.html) that you can use as the basis for your code.\n\nUsing OAuth 2.0 with phones, tablets and other devices\n------------------------------------------------------\n\nWhen writing Android applications, developers can take advantage of [Google Play services](http://developer.android.com/google/play-services/index.html) to handle the authorization details. Google Play services offers a [standard authorization flow for all Google APIs](http://developer.android.com/google/play-services/auth.html), including APIs for the YouTube platform. This approach will provide a far superior user experience for users of your Android application than a custom authentication using ClientLogin.\n\nOn iOS devices, Google provides two options:\n\n\n- the [Google+ Platform for iOS](https://developers.google.com/+/mobile/ios/), which integrates sign-in for Google products and also enables social features\n- the [gtm-oauth2 toolkit](https://github.com/google/gtm-oauth2), which provides an authorization UIWebView and manages tokens\n\n\u003cbr /\u003e\n\nFor devices that are meant to act as \"second screen\" devices or devices such as televisions without easy-to-use input mechanisms, [OAuth 2.0 for Devices](https://developers.google.com/accounts/docs/OAuth2ForDevices) is the preferred approach. OAuth 2.0 for Devices works by presenting a unique code for a user when an authorization request is required. At this point, users are asked to browse to \u003chttp://google.com/device\u003e on another device, such as a laptop or a phone, and enter in the unique code. The application presents a screen that looks something like this:\n\nWhile the user is entering the code on another device, the application periodically polls to see if the code has been entered. Once it has, it retrieves a token for making API calls. To see this in action, check out [the demo](http://stb-web-app.appspot.com/static/index.html), which can be run on any web-enabled device. The API itself is platform-agnostic, making it useful for devices that don't have web rendering capabilities. We've posted [sample code in Python](https://code.google.com/p/gdata-samples/source/browse/trunk/ytplayer/stb-web-app/?r=238) for the demo to be used as a reference.\n\nSummary\n-------\n\nOAuth 2.0 authorization provides flexibility for developers that require YouTube authorization. Developers familiar with ClientLogin may find that setting up their applications to use OAuth 2.0 requires slightly more work to get started, but once ported, OAuth 2.0 applications offer more flexibility, security and usability across multiple platforms for end users.\n\nIf you have any more questions about OAuth 2.0 or any of the examples in this article, please feel feel to ask with the [youtube-api tag on StackOverflow](http://stackoverflow.com/questions/tagged/youtube-api)."]]
