Get post put delete

Запрос — это сообщение, посылаемое клиентом серверу.

Существует два формата HTTP запроса:

Запрос = Простой-Запрос | Полный-Запрос

Простой-Запрос = "GET" SP Запрашиваемый-URI CRLF

*(Общий-Заголовок | Заголовок-Запроса | Заголовок-Содержания ) CRLF

Строка Статус начинается со строки с названием метода, за которым следует URI-Запроса и использующаяся версия протокола. Строка Статус заканчивается символами CRLF. Элементы строки разделяются пробелами (SP). В Строке Статус не допускаются символы LF и CR, за исключением заключающей последовательности CRLF.

Строка-Статус = Метод SP URI-Запроса SP Версия-HTTP CRLF

поле Метод указывается метод, который должен быть применен к ресурсу, идентифицируемому URI-Запроса. Названия методов чувствительны к регистру. Существующий список методов может быть расширен.

Метод = "GET" | "HEAD" | "PUT" | "POST" | "DELETE" | "LINK" | "UNLINK" | дополнительный-метод

HEAD.

Метод HEAD аналогичен методу GET, за исключением того, что в ответе сервер не возвращает Тело-Ответа. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса.

28. Интерфейс servlet, класс HttpServlet

Пакеты сервлетов определяют два абстрактных класса, которые реализуют интерфейс Servlet: класс GenericServlet (из пакета javax.servlet) и класс HttpServlet (из пакета javax.servlet.http). Эти классы предоставляют реализацию по умолчанию для всех методов интерфейса Servlet. Большинство разработчиков используют либо класс GenericServlet, либо класс HttpServlet, и замещают некоторые или все методы.

Метод service, как правило, переопределяется, чтобы иметь возможность различать стандартные методы запросов, получаемые от Web-браузера клиента. Двумя наиболее распространенными типами запросов HTTP (их также называют методами запросов) являются get и post. Запрос get получает (или извлекает) информацию. Запрос post помещает (или отправляет) данные на сервер. Типичное применение метода post — отправка на сервер информации для аутентификации, или данных из формы, в которую пользователь ввел информацию.

В классе HttpServlet определены методы doGet и doPost для реакции на запросы типа get и post клиента. Эти методы вызываются методом service класса HttpServlet, который, в свою очередь, вызывается при поступлении запроса на сервер. Методы doGet и doPost принимают в качестве параметров объекты HttpServletRequest и HttpServletResponse, которые дают возможность осуществлять взаимодействие между клиентом и сервером.

· String getParameter(String name) Получение из запроса значения параметра. Наименование параметра определено значением name.

· Enumeration getParameterNames() Получение из запроса имен всех параметров.

· String[ ] getParameterValues(String name) Для параметра с несколькими значениями данный метод возвращает строковый массив.

· Cookie[ ] getCookies () Получение массива объектов Cookie, сохраненных на компьютере клиента. Cookie могут быть использованы для уникальной идентификации клиента сервером.

· HttpSession getSession(boolean create) Возвращает объект HttpSession текущего сеанса клиента. Если параметр create равен true и объект HttpSession не существует, то создается новый объект HttpSession.

· void addCookie (Cookie cookie) Метод используется для добавления Cookie в заголовок ответа клинту. Установленный максимальный возвраст Cookie, а также разрешение клиентом хранения Cookie определяют, будут ли Cookies сохранены на клиенте и время их хранения.

· ServletOutputStream getOutputStream() Получение бинарного потока вывода для отправления бинарных данных клиенту.

· PrintWriter getWriter Получение символьного потока вывода для отправления текстовых данных клиенту.

· void setContentType(String type) Определение MIME-типа ответа браузеру. MIME-тип помогает браузеру определить, как отображать данные. Например, MIME-тип "text/html" указывает, что ответ является HTML-документом, поэтому браузер отображает HTML-страницу.

doDelete(HttpServletRequest req, HttpServletResponse resp)

Called by the server (via the service method) to allow a servlet to handle a DELETE request.

doGet(HttpServletRequest req, HttpServletResponse resp)

Called by the server (via the service method) to allow a servlet to handle a GET request.

doHead(HttpServletRequest req, HttpServletResponse resp)

Receives an HTTP HEAD request from the protected service method and handles the request.

doOptions(HttpServletRequest req, HttpServletResponse resp)

Called by the server (via the service method) to allow a servlet to handle a OPTIONS request.

doPost(HttpServletRequest req, HttpServletResponse resp)

Called by the server (via the service method) to allow a servlet to handle a POST request.

doPut(HttpServletRequest req, HttpServletResponse resp)

Called by the server (via the service method) to allow a servlet to handle a PUT request.

doTrace(HttpServletRequest req, HttpServletResponse resp)

Called by the server (via the service method) to allow a servlet to handle a TRACE request.

Returns the time the HttpServletRequest object was last modified, in milliseconds since midnight January 1, 1970 GMT.

service(HttpServletRequest req, HttpServletResponse resp)

Receives standard HTTP requests from the public service method and dispatches them to the doXXX methods defined in this class.

service(ServletRequest req, ServletResponse res)

Dispatches client requests to the protected service method.

29. Создание REST сервисов, JAX RS

REST это архитектура, которая базируется на стандартах Web и на Http протоколе.

Restfull сервисы основаны на методах HTTP (GET, PUT, POST, DELETE) и концепции REST.

Шаг № 1 — Предварительный.

Установите контейнер сервлетов (например, Tomcat 6), Maven и вашу любимую IDE.

Шаг № 2 – Создание проекта.

Надо создать Dynamic Web Project

Шаг № 3 – Создать класс

Создать Java-класс, который бы описывал методы Get, Put и т.д. для различных типов данных, чтобы обслуживать запросы к сервису.

Затем надо зарегистрировать Jersy в качестве распределителя запросов для REST-запросов (для этого надо модифицировать файл web.xml).

Шаг № 5 – Запустить службу.

Шаг № 6 – Создать клиента.

JAX-RS поддерживает автоматическое создание XML и JSON посредством JAXB.

30. Связка JAXB и JAX RS, переключение типов возвращаемого контента (xml, json)

JAX-RS поддерживает автоматическое создание XML и JSON посредством JAXB.

// Get XML for application

// Get JSON for application

JSP

JSP (JavaServer Pages) — технология, позволяющая веб-разработчикам легко создавать содержимое, которое имеет как статические, так и динамические компоненты. По сути, страница JSP является текстовым документом, который содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP элементы, которые конструируют динамическое содержимое. Кроме этого могут использоваться библиотеки JSP тегов, а также EL (Expression Language), для внедрения Java-кода в статичное содержимое JSP-страниц.

JSP — одна из высокопроизводительных технологий, так как весь код страницы транслируется в java-код сервлета с помощью компилятора JSP страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Сервлет-контейнеры (Apache Tomcat), способные исполнять JSP страницы, написаны на платформонезависимом языке Java, который может работать под различными операционными системами и платформами. JSP страницы загружаются на сервере и управляются из структуры специального Java server packet, который называется Java EE Web Application, в большинстве своём упакованная в файловые архивы .war и .ear.

Выгода, которую дает технология JSP в сравнении с другими веб-технологиями заключается в том, что JSP является платформонезависимой, переносимой и легко расширяемой технологией для разработки веб-приложений.

JavaServer Pages (JSP) позволяют отделить динамическую часть страниц от статического HTML. Процедура довольно проста, создаёте обычный код HTML (статический), а динамическую часть заключаете в специальные теги " ".

Имя вашего хоста:

JSP страницы имеют расширение .jsp и размещаются там же, где и обычные Web страницы. Структура таких страниц может состоять из пяти конструкций: HTML, комментарии, скриптовые элементы, директивы и действия. JSP страница при компиляции преобразуется в обычный сервлет со статическим содержимым, которое направляется в поток вывода, связанный с методом service. Поэтому при первом запросе этот процесс может вызвать некую задержку, но в большинстве своём незаметную первому пользователю. Комментарии в документе или программе служат к объяснению содержимого. Они не являются причиной замедления программы, так как транслятор и исполнитель их игнорируют. Скриптовые элементы позволяют вам указать код на языке Java, который впоследствии станет частью конечного сервлета, директивы дадут вам возможность управлять всей структурой сервлета, а действия служат для задания существующих используемых компонентов, а также для контроля над поведением движка JSP. Для упрощения работы со скриптами имеются заранее определённые переменные, такие как request, response, pageContext, session, out, application, config, page, exception. Пример JSP страницы с использованием всех составляющих JSP конструкции:

Cпецификация JSP различает три типа скриптовых элементов:

Объявления обычно используются для определения переменных, методов, внутренних классов и остальных действующих Java конструкций на уровне класса. В выражения вкладываются любые действующие выражения Java. С помощью скриплетов в JSP страницы вкладываются работающие части кода Java. Все эти элементы начинаются знаками .

JSP страница может послать сообщение соответствующему контейнеру с указаниями какие действия необходимо провести. Эти сообщения называются директивами. Все директивы начинаются с . Директивы в JSP странице приводят к тому, что контейнер пошлёт заявку на исполнение определённой службы, которая в генерированном документе не объявляется.

Действия JSP используют конструкции с синтаксисом XML для управления работой движка сервлета. Вы можете динамически подключать файл, многократно использовать компоненты JavaBeans, направить пользователя на другую страницу или сгенерировать HTML для Java plugin.

JSF

JavaServer Faces (JSF) — это фреймворк для веб-приложений, написанный на Java. Он служит для того, чтобы облегчать разработку пользовательских интерфейсов для Java EE приложений. В отличие от прочих MVC фреймворков, которые управляются запросами, подход JSF основывается на использовании компонентов. Состояние компонентов пользовательского интерфейса сохраняется, когда пользователь запрашивает новую страницу и затем восстанавливается, если запрос повторяется. Для отображения данных обычно используется JSP

Технология JavaServer Faces включает:

· Набор API для представления компонент пользовательского интерфейса (UI) и управления их состоянием, обработкой событий и валидацией вводимой информации, определения навигации, а также поддержку интернационализации (i18n) и доступности (accessibility).

· Специальная библиотека JSP тегов для выражения интерфейса JSF на JSP странице.

Призванная быть гибкой, технология JavaServer Faces усиливает существующие, стандартные концепции пользовательского интерфейса (UI) и концепции Web-уровня без привязки разработчика к конкретному языку разметки, протоколу или клиентскому устройству. Классы компонентов пользовательского интерфейса, поставляемые вместе с технологией JavaServer Faces, содержат функциональность компонент, а не специфичное для клиента отображение, открывая тем самым возможность рендеринга JSF-компонент на различных клиентских устройствах.

33. Оптимизация JVM

Оптимизация производительности Java

Ниже перечислены основные особенности, влияющие на производительность программ на Java:

· Для того чтобы при выполнении большого числа операций со строками избежать создания ненужных объектов, которые потом будет необходимо удалять, вместо конкатенации строк можно использовать StringBuffer.

· Ограничтье число операций записи в консоль Java для снижения нагрузки при выполнении операций со строками, форматировнии текста и выводе данных.

· По возможности создавайте объекты простых типов; это позволит ограничить использование системных ресурсов.

· Заносите часто используемые объекты в кэш; это позволит уменьшить нагрузку на функцию сбора мусора и избежать многократного создания этих объектов.

· Объединяйте в группы внутренние операции для снижения числа вызовов Java Native Interface (JNI), когда это возможно.

· Для снижения числа процессов в JVM и операционной системе не применяйте синхронизированные методы без необходимости.

· Инициируйте функцию сбора мусора только при необходимости. Запускать эту функцию рекомендуется только во время простоя или невысокой загруженности системы.

· Используйте переменные типа int, а не long всегда, когда это возможно, потому что 32-разрядные операции выполняются быстрее, чем 64-разрядные.

· Объявляйте методы как окончательные всегда, когда это возможно. В JVM такие методы обрабатываются быстрее.

· Для снижения числа операций по объявлению переменных создавайте константы с ключевым словом static final.

· Постарайтесь снизить число ссылок "cast" и "instanceof", поскольку соответствующие действия выполняются не при компиляции, а во время выполнения.

· Во всех возможных ситуациях используйте массивы вместо векторов.

· Для повышения производительсности добавляйте и удаляйте элементы из конца вектора.

· Компилируйте программы на Java с опцией -O.

JIT typically causes a slight delay in initial execution of an application, due to the time taken to load and compile the bytecode. Sometimes this delay is called "startup time delay". In general, the more optimization JIT performs, the better the code it will generate, but the initial delay will also increase. A JIT compiler therefore has to make a trade-off between the compilation time and the quality of the code it hopes to generate. However, it seems that much of the startup time is sometimes due to IO-bound operations rather than JIT compilation

One possible optimization, used by Sun’s HotSpot Java Virtual Machine, is to combine interpretation and JIT compilation. The application code is initially interpreted, but the JVM monitors which sequences of bytecode are frequently executed and translates them to machine code for direct execution on the hardware. For bytecode which is executed only a few times, this saves the compilation time and reduces the initial latency; for frequently executed bytecode, JIT compilation is used to run at high speed, after an initial phase of slow interpretation. Additionally, since a program spends most time executing a minority of its code, the reduced compilation time is significant. Finally, during the initial code interpretation, execution statistics can be collected before compilation, which helps to perform better optimization.[2]

The correct tradeoff can vary due to circumstances. For example, Sun’s Java Virtual Machine has two major modes—client and server. In client mode, minimal compilation and optimization is performed, to reduce startup time. In server mode, extensive compilation and optimization is performed, to maximize performance once the application is running by sacrificing startup time. Other Java just-in-time compilers have used a runtime measurement of the number of times a method has executed combined with the bytecode size of a method as a heuristic to decide when to compile.[3] Still another uses the number of times executed combined with the detection of loops.[4] In general, it is much harder to accurately predict which methods to optimize in short-running applications than in long-running ones.[5]

Native Image Generator (Ngen) by Microsoft is another approach at reducing the initial delay.[6] Ngen pre-compiles (or "pre-jits") bytecode in a Common Intermediate Language image into machine native code. As a result, no runtime compilation is needed. .NET framework 2.0 shipped with Visual Studio 2005 runs Ngen on all of the Microsoft library DLLs right after the installation. Pre-jitting provides a way to improve the startup time. However, the quality of code it generates might not be as good as the one that is jitted, for the same reasons why code compiled statically, without profile-guided optimization, cannot be as good as JIT compiled code in the extreme case: the lack of profiling data to drive, for instance, inline caching.[7]

There also exist Java implementations that combine an AOT (ahead-of-time) compiler with either a JIT compiler (Excelsior JET) or interpreter (GNU Compiler for Java.)

Тема 7: Определение методов HTTP (HTTP Method Definitions). Методы HTTP запросов

  • 05.06.2016
  • HTTP протокол, Сервера и протоколы
  • Один комментарий

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. В этой записи мы изучим с тобой HTTP методы. Для начала мы с тобой разберемся с видами HTTP методов, потом разберем безопасные HTTP методы, выделим идемпотентные методы. После чего я перечислю все HTTP методы с их кратким описание, а далее мы разберем каждый метод в отдельности. Надеюсь, примеры, используемые в данной публикации помогут тебе понять как работают все эти методы: GET, POST, HEAD, CONNECT, PUT, DELETE, OPTIONS и TRACE. Как всегда, если что-то непонятно или есть какие-то дополнения или заметил неточность — не стесняйся написать комментарий.

Определение методов HTTP (HTTP Method Definitions). Описание методов HTTP запросов

Виды HTTP методов запроса

Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Стандарт HTTP 1.1 насчитывает восемь методов, но набор методов может быть расширен, хотя и не будет поддерживаться другими HTTP приложениями, которые полностью соответствую букве стандарта. Каждый HTTP запрос должен содержать метод. HTTP методы запроса делятся на идемпотентные и безопасные методы. Дам короткую справку: идемпотентные методы в HTTP должны при большом количестве идентичных HTTP запросах иметь такой же эффект, как и при одном единственном запросе, но в то же время ответ HTTP сервера не обязательно должен быть тем же самым. Вот такое вот противоречие.

Безопасные HTTP методы и идемпотентные HTTP методы запросов

Давайте посмотрим на разницу между HTTP методами. Сперва рассмотрим безопасные методы. HTTP стандарт четко говорит о том, что программа, которая работает с сетью интернет, представляет пользователя, поэтому она должна информировать пользователя о любых действиях, которые происходят и которые он может произвести, но которые могут иметь непредсказуемые значения для самого пользователя или для других лиц. Другими словами: ваш браузер должен информировать вас о любых действия во время HTTP соединения. Это не всегда так, но, по крайней мере, так сказано в стандарте протокола HTTP 1.1.

Безопасные HTTP методы (Safe method HTTP)

На данный момент принято соглашение о том, что HTTP методы GET и HEAD никогда не должны иметь иного значения, кроме загрузки, поэтому данные HTTP методы нужно рассматривать, как безопасные, это требование HTTP. Поэтому ваш браузер, когда используются методы POST, PUT или DELETE предупреждает вас о том, что может произойти потенциально опасное действие и спрашивает: нужно ли его выполнить.

Идемпотентные HTTP методы (Idempotent Methods HTTP)

Я уже вкратце объяснил суть идемпотентных HTTP методов: при использование таких методов побочные эффекты одинаковы как в случае однократного запроса, так и в случае многократного повторения одного и того же запроса, т.е. нагрузка одинакова, но HTTP ответ от сервера может поступать каждый раз разный. К идемпотентным методам относятся следующие HTTP методы: GET, HEAD, PUT и DELETE. Так же эффектом идемпотентности обладают HTTP методы OPTIONS и TRACE.

Краткий обзор HTTP методов

Давайте перечислим все методы HTTP протокола и дадим им краткое описание. Для удобства сведем HTTP методы в таблицу

Номер HTTP метод и его описание
1 HTTP метод GET

Метода GET в HTTP используется для получения информации от сервера по заданному URI (URI в HTTP). Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.

2 HTTP метод HEAD

HTTP метод HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.

3 HTTP метод POST

HTTP метод POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.

4 HTTP метод PUT

HTTP метод PUT используется для загрузки содержимого запроса на указанный в этом же запросе URI.

5 HTTP метод DELETE

HTTP метод DELETE удаляет указанный в URI ресурс.

6 HTTP метод CONNECT

HTTP метод CONNECT преобразует существующее соединение в тоннель.

7 HTTP метод OPTIONS

HTTP метод OPTIONS используется для получения параметров текущего HTTP соединения.

8 HTTP метод TRACE

HTTP метод TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.

Мы вкратце рассмотрели все HTTP методы и дали им короткую характеристику. Давайте теперь более подробно остановимся на каждом из HTTP методов и приведем несколько примеров использования HTTP методов.

Описание HTTP метода GET. Пример использования HTTP метода GET

HTTP метод GET позволяет получать информацию с HTTP сервера. Информация, получаемая от сервера может быть любой, главное, чтобы она была в форме HTTP объекта, доступ к информации при использовании метода GET осуществляется через URI. Часто бывает так, что HTTP метод GET обращается к какому-то коду, а не к конкретной страницы (все CMS генерируют контент налету), поэтому метод GET работает так, что мы получаем не исходный код, который генерирует текст, а сам текст.

HTTP метод GET бывает двух видов: условный метод GET и частичный метод GET. Давайте сперва посмотрим на условный метод GET. Когда используется условный HTTP метод GET, то к HTTP сообщению добавляются следующие поля заголовков: If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, или If-Range. Значение таких полей является какое-либо условие и если это условие выполняется, то происходит передача объекта, который хранится по указанному URI, если же условие не выполняется, то и сервер не передает никаких данных. Условный HTTP метод GET предназначен для уменьшения нагрузки на сеть.

Давайте теперь посмотрим на особенности работы частичного HTTP метода GET. Особенность частичного метода GET заключается в том, что в его заголовке присутствует поле Range. Когда используется частичные метод GET полезная информация, предназначенная для человека передается кусками, после чего она из этих кусков собирается. Не напоминает ли это вам скачивание файлов по HTTP протоколу, когда мы можем остановить загрузку, отключить браузер, потом опять включить браузер и закачка будет происходить ровно с того места, где она была приостановлена. Не стоит забывать, что поля заголовков — это параметры HTTP протокола, которые определяют, как будут работать клиент и сервер.

Сервер может кэшировать ответы на запросы с HTTP методом GET, но при соблюдение определенных требований, о которых мы поговорим чуть позже. Давайте лучше самостоятельно напишем HTTP запрос с методом GET и посмотрим, какой ответ мы можем получить от сервера:

So, I was looking through some articles on creating REST API’s. And some of them suggest using all types of HTTP requests: like PUT DELETE POST GET . We would create for example index.php and write API this way:

OK, granted — I don’t know much about web services (yet). But, wouldn’t it be easier to just accept JSON object through regular POST or GET (that would contain method name and all parameters) and then respond in JSON as well. We can easily serialize/deserialize via PHP’s json_encode() and json_decode() and do whatever we want with that data without having to deal with different HTTP request methods.

Am I missing something?

UPDATE 1:

Ok — after digging through various API’s and learning a lot about XML-RPC, JSON-RPC, SOAP, REST I came to a conclusion that this type of API is sound. Actually stack exchange is pretty much using this approach on their sites and I do think that these people know what they are doing Stack Exchange API.

9 Answers 9

The idea of REpresentational State Transfer is not about accessing data in the simplest way possible.

You suggested using post requests to access JSON, which is a perfectly valid way to access/manipulate data.

REST is a methodology for meaningful access of data. When you see a request in REST, it should immediately be apparant what is happening with the data.

is likely going to return a list of chevy cars. A good REST api might even incorporate some output options in the querystring like ?output=json or ?output=html which would allow the accessor to decide what format the information should be encoded in.

After a bit of thinking about how to reasonably incorporate data typing into a REST API, I’ve concluded that the best way to specify the type of data explicitly would be via the already existing file extension such as .js , .json , .html , or .xml . A missing file extension would default to whatever format is default (such as JSON); a file extension that’s not supported could return a 501 Not Implemented status code.

is likely going to create a new chevy malibu in the db with the associated colors. I say likely as the REST api does not need to be directly related to the database structure. It is just a masking interface so that the true data is protected (think of it like accessors and mutators for a database structure).

Now we need to move onto the issue of idempotence. Usually REST implements CRUD over HTTP. HTTP uses GET , PUT , POST and DELETE for the requests.

A very simplistic implementation of REST could use the following CRUD mapping:

There is an issue with this implementation: Post is defined as a non-idempotent method. This means that subsequent calls of the same Post method will result in different server states. Get, Put, and Delete, are idempotent; which means that calling them multiple times should result in an identical server state.

This means that a request such as:

could actually be implemented as:

will result in the same server state if you call it once, or if you call it 1000 times.

A better way of handling the removal of the oldest item would be to request:

and use the ID from the resulting data to make a delete request:

An issue with this method would be if another /cars item was added between when /oldest was requested and when the delete was issued.

This is a security and maintainability question.

safe methods

Whenever possible, you should use ‘safe’ (unidirectional) methods such as GET and HEAD in order to limit potential vulnerability.

idempotent methods

Whenever possible, you should use ‘idempotent’ methods such as GET, HEAD, PUT and DELETE, which can’t have side effects and are therefore less error prone/easier to control.

In short, REST emphasizes nouns over verbs. As your API becomes more complex, you add more things, rather than more commands.

You asked:

wouldn’t it be easier to just accept JSON object through normal $_POST and then respond in JSON as well

From the Wikipedia on REST:

RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of it

From what (little) I’ve seen, I believe this is usually accomplished by maximizing the use of existing HTTP verbs, and designing a URL scheme for your service that is as powerful and self-evident as possible.

Custom data protocols (even if they are built on top of standard ones, such as SOAP or JSON) are discouraged, and should be minimized to best conform to the REST ideology.

SOAP RPC over HTTP, on the other hand, encourages each application designer to define a new and arbitrary vocabulary of nouns and verbs (for example getUsers(), savePurchaseOrder(. )), usually overlaid onto the HTTP ‘POST’ verb. This disregards many of HTTP’s existing capabilities such as authentication, caching and content type negotiation, and may leave the application designer re-inventing many of these features within the new vocabulary.

The actual objects you are working with can be in any format. The idea is to reuse as much of HTTP as possible to expose your operations the user wants to perform on those resource (queries, state management/mutation, deletion).

You asked:

There is a lot more to know about REST and the URI syntax/HTTP verbs themselves. For example, some of the verbs are idempotent, others aren’t. I didn’t see anything about this in your question, so I didn’t bother trying to dive into it. The other answers and Wikipedia both have a lot of good information.

Also, there is a lot to learn about the various network technologies built on top of HTTP that you can take advantage of if you’re using a truly restful API. I’d start with authentication.

In regards to using extension to define data type. I noticed that MailChimp API is doing it, but I don’t think this is a good idea.

My sound like a good idea, but I think "older" approach is better — using HTTP headers

Also HTTP headers are much better for cross data type communication (if ever someone would need it)

This phenomenon exists because of the uniform interface constraint. REST likes using already existing standards instead of reinventing the wheel. The HTTP standard has already proven to be highly scalable (the web is working for a while). Why should we fix something which is not broken?!

note: The uniform interface constraint is important if you want to decouple the clients from the service. It is similar to defining interfaces for classes in order to decouple them from each other. Ofc. in here the uniform interface consists of standards like HTTP, MIME types, URI, RDF, linked data vocabs, hydra vocab, etc.

Good Semantics is important in programming.

Utilizing more methods besides GET/POST will be helpful because it will increase the readability of your code and make it easier to maintain.

Because you know GET will retrieve data from your api. You know POST will add new data to your system. You know PUT will make updates. DELETE will delete rows etc, etc,

I normally structure my RESTFUL Web Services so that I have a function callback named the same thing as the method.

I use PHP, so I use function_exists (I think its called). If the function doesn’t exist, I throw a 405 (METHOD NOT ALLOWED).

Bill Venners: In your blog post entitled "Why REST Failed," you said that we need all four HTTP verbs—GET, POST, PUT, and DELETE— and lamented that browser vendors only GET and POST." Why do we need all four verbs? Why aren’t GET and POST enough?

Elliotte Rusty Harold: There are four basic methods in HTTP: GET, POST, PUT, and DELETE. GET is used most of the time. It is used for anything that’s safe, that doesn’t cause any side effects. GET is able to be bookmarked, cached, linked to, passed through a proxy server. It is a very powerful operation, a very useful operation.

POST by contrast is perhaps the most powerful operation. It can do anything. There are no limits as to what can happen, and as a result, you have to be very careful with it. You don’t bookmark it. You don’t cache it. You don’t pre-fetch it. You don’t do anything with a POST without asking the user. Do you want to do this? If the user presses the button, you can POST some content. But you’re not going to look at all the buttons on a page, and start randomly pressing them. By contrast browsers might look at all the links on the page and pre-fetch them, or pre-fetch the ones they think are most likely to be followed next. And in fact some browsers and Firefox extensions and various other tools have tried to do that at one point or another.

PUT and DELETE are in the middle between GET and POST. The difference between PUT or DELETE and POST is that PUT and DELETE are *idempotent, whereas POST is not. PUT and DELETE can be repeated if necessary. Let’s say you’re trying to upload a new page to a site. Say you want to create a new page at http://www.example.com/foo.html, so you type your content and you PUT it at that URL. The server creates that page at that URL that you supply. Now, let’s suppose for some reason your network connection goes down. You aren’t sure, did the request get through or not? Maybe the network is slow. Maybe there was a proxy server problem. So it’s perfectly OK to try it again, or again—as many times as you like. Because PUTTING the same document to the same URL ten times won’t be any different than putting it once. The same is true for DELETE. You can DELETE something ten times, and that’s the same as deleting it once.

By contrast, POST, may cause something different to happen each time. Imagine you are checking out of an online store by pressing the buy button. If you send that POST request again, you could end up buying everything in your cart a second time. If you send it again, you’ve bought it a third time. That’s why browsers have to be very careful about repeating POST operations without explicit user consent, because POST may cause two things to happen if you do it twice, three things if you do it three times. With PUT and DELETE, there’s a big difference between zero requests and one, but there’s no difference between one request and ten.

Update:

Idempotent methods An idempotent HTTP method is a HTTP method that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. Again, this only applies to the result, not the resource itself. This still can be manipulated (like an update-timestamp, provided this information is not shared in the (current) resource representation.

Consider the following examples:

The first example is idempotent: no matter how many times we execute this statement, a will always be 4. The second example is not idempotent. Executing this 10 times will result in a different outcome as when running 5 times. Since both examples are changing the value of a, both are non-safe methods.


[an error occurred while processing the directive]
Карта сайта