Як писати api
Full-stack developer (Symfony, Angular)
Статей вистачає, можете жартуючи заповнити, але врят-ли что-то-нове вийде.
Структуру методів, що і як має повертати краще обговоріть з iOS розробником, який буде потім імплеменіть цю справу. Якщо такого немає - максимально розбийте все на атомарні операції, спростите взаємодія, прикиньте самі які методи можуть знадобитися (уявіть що ви пишете API не для кого-то, а, наприклад, для сторінки, яка через AJAX все видерает).
З приводу реалізації - банальна сериализация замість рендрінга, більше відмінностей немає. Є купа готових компонентів які добре підходять для сериализации туди і назад. Свій такий компонент теж пишеться досить швидко.
Я не бачив жодного RESTfull API для серйозних додатків, тобіш так, воно то REST але не повністю, так що морочитися тут не варто. Досить просто обробляти якісь базові заголовки і GET / POST запити. GET для вибірок - тобіш дані в базі при запиті не змінюються, хіба що якісь лічильники, а POST для створення записів в базі (по феншую результат роботи функції повинен повертатися тільки HTTP заголовки, серед яких є GET запит з URI нового об'єкта, але на практиці ніхто не паритися і повертає весь об'єкт або його частина).
Можна звичайно скористатися SOAP апішкамі, але з досвіду скажу що воно придатне тільки при розробці оочень простих API, і толку від нього мало. Якщо клієнтом, звичайно, буде додаток написане на C # .NET - тоді сміливо SOAP і тільки SOAP, вам по суті різниці в реалізації (мається на вигляді за часом) мінімум, а розробнику клієнта буде набагато простіше. А ось на iOS з SOAP все досить сумно.
Наводити приклад хороших побоююся, тому що може викликати баттхёрт в гілці. )
Як на мене - є лише один очевидний критерій відмінного API. Його можна сформулювати приблизно так: клієнт повинен бути абсолютно упевнений в тому, які варіанти відповідей він отримає від сервісу ще до того, як відправить запит. Тобто ніколи не повинно виникати ситуації, коли API повертає несподівану структуру даних, не той формат або дивні помилки.
Повертаючись до Facebook - справа не в переусложнённості. Наведу лише один приклад поведінки їх API, від якого я впадав в ступор: якщо ви запитуєте дані об'єкта event, який був вилучений на стороні сервера (закінчився термін, скасовано і т.п.) - інтуїтивно очікуєте щось типу масиву JSON з кодом помилки і текстом а-ля «Об'єкт відноситься (не знайдений, скасований.». Але Facebook поверне рядок «помилковий запит». Тобто мало того, що помилка взагалі не адекватна, так ще й формат повернення - текст! Про такі « дрібниці », як непередбачувані дані всередині властивостей одних і тих же типів об'єктів - можна і не згадувати. Не робіть так ніко да.)
Згоден повністю, спасибі за розгорнуту відповідь. Думаю, це банальна помилка розробників FB.
Є дуже хороший модуль для Node.js, у якого можеш підглянути цікаві ідеї реалізації RESTful API, - restify. Також раджу подивитися як реалізований API у Amazon. Врахуй, що це реалізації для enterprise використання, а реальної життя можна обійтися більш простими рішеннями, наприклад відкинувши непотрібні http headers.
Програміст, в основному web
Наскільки я знаю, найбільш популярною парадигмою створення API на даний момент є REST
Про досвід створення API на вскидку знайшов такі статті: 1. 2.
За досвід скажу, що тут найважливіше грамотно все спланувати. Знайдіть проект по можливості схожий з Вашим цільовим який надає документацію за своїм API, і почитайте її.