Diferença entre Soap e Rest

SOAP

SOAP é um protocolo de transferência de mensagens em formato XML para uso em ambientes distribuídos. O padrão SOAP funciona como um tipo de framework que permite a interoperabilidade entre diversas plataformas com mensagens personalizadas.

Aplicando este padrão em Web Services, geralmente usa-se o WSDL para descrever a estrutura das mensagens SOAP e as ações possíveis em um endpoint.

Uma das maiores vantagens disso é que várias linguagens e ferramentas conseguem ler e gerar mensagens facilmente. Várias linguagens de programação permitem a geração de objetos de domínio, Stubs e Skeletons a partir da definição do WSDL, permitindo a comunicação remota via RPC através de chamadas a métodos remotod, inclusive com argumentos complexos, como se fossem chamadas locais.

O problema desse padrão, é que ele adiciona um overhead considerável, tanto por ser em XML quanto por adicionar muitas tags de meta-informação. Além disso, a serialização e desserialização das mensagens pode consumir um tempo considerável.

REST

REST é outro um protocolo de comunicação, baseado no protocolo de hipermídia HTTP. Porém ele não impõe restrições ao formato da mensagem, apenas no comportamento dos componentes envolvidos.

A maior vantagem do protocolo REST é sua flexibilidade. O desenvolvedor pode optar pelo formato mais adequado para as mensagens do sistema de acordo com sua necessidade específica. Os formais mais comuns são Json, XML e texto puro, mas em teoria qualquer formato pode ser usado.

Isso nos leva a outra vantagem: quase sempre Web Services que usam REST são mais “leves” e, portanto, mais rápidos.

O problema com o REST pode surgir justamente por causa de suas vantagens. Como a definição do corpo de dados fica totalmente a cargo do desenvolvedor, os problemas de interoperabilidade são mais comuns.

SOAP ou REST?

Aviso: Esta é uma opinião pragmática.

Em geral, SOAP é uma boa opção para instituições com padrões rígidos e ambientes complexos (várias plataformas e sistemas). Muitas ferramentas corporativas (como ESB) tiram vantagem do padrão e possibilitam filtrarem, enfileiramento, classificação e redirecionamento das mensagens trocadas entre sistemas.

No restante, para uso no dia-a-dia, não vejo motivos concretos para não usar REST e Json. Praticamente todas as plataformas e linguagens modernas que conheço suportam esses conceitos e a solução final é muito mais simples do que o equivalente em SOAP.

Além disso, integrações com alto volume de requisições são inviáveis em SOAP. REST é capaz de atender volume e complexidade sem dificuldades, exigindo apenas um mínimo de experiência do desenvolvedor para estabelecer e reforçar os padrões adequados.

Fonte: http://pt.stackoverflow.com/questions/11183/diferen%C3%A7as-de-tipos-de-web-service-soap-rest-xml

Codificação de caracteres em url (tabela conversão)

Codificação de caracteres em endereços URL

Quando passam variáveis em endereços URL, às vezes, é necessário codificar certos caracteres. Isto é, substituir uma caracter por seu código ASCII em formato hexadecimal. A seguir, apresentam os os caracteres que se codificam mais frequentemente:

Tabela de caracteres frequentes

Caracter Código Caracter Código Caracter Código Caracter Código
(espaço) %20 ? %3f & %26 % %25
# %23 / %2f < %3c > %3e
: %3a / %2f | %7c ; %3b

Script de conversão

Tabela completa

æ

apagar
tab
nova linha

salto de linha

espaço
!

#
$
%
&

(
)
*
+
,

.
/

%00
%01
%02
%03
%04
%05
%06
%07
%08
%09
%0a
%0b
%0c
%0d
%0e
%0f
%10
%11
%12
%13
%14
%15
%16
%17
%18
%19
%1a
%1b
%1c
%1d
%1e
%1f
%20
%21
%22
%23
%24
%25
%26
%27
%28
%29
%2a
%2b
%2c
%2d
%2e
%2f
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
[
\
]
^
_
%30
%31
%32
%33
%34
%35
%36
%37
%38
%39
%3a
%3b
%3c
%3d
%3e
%3f
%40
%41
%42
%43
%44
%45
%46
%47
%48
%49
%4a
%4b
%4c
%4d
%4e
%4f
%50
%51
%52
%53
%54
%55
%56
%57
%58
%59
%5a
%5b
%5c
%5d
%5e
%5f
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
~

€


ƒ




ˆ

Š

Œ

Ž

%60
%61
%62
%63
%64
%65
%66
%67
%68
%69
%6a
%6b
%6c
%6d
%6e
%6f
%70
%71
%72
%73
%74
%75
%76
%77
%78
%79
%7a
%7b
%7c
%7d
%7e
%7f
%80
%81
%82
%83
%84
%85
%86
%87
%88
%89
%8a
%8b
%8c
%8d
%8e
%8f







˜

š

œ

ž
Ÿ

¡
¢
£

¥
|
§
¨
©
ª
«
¬
¯
®
¯
°
±
²
³

µ

·
¸
¹
º
»
¼
½
¾
¿

%90
%91
%92
%93
%94
%95
%96
%97
%98
%99
%9a
%9b
%9c
%9d
%9e
%9f
%a0
%a1
%a2
%a3
%a4
%a5
%a6
%a7
%a8
%a9
%aa
%ab
%ac
%ad
%ae
%af
%b0
%b1
%b2
%b3
%b4
%b5
%b6
%b7
%b8
%b9
%ba
%bb
%bc
%bd
%be
%bf
À
Á
Â
Ã
Ä
Å
Æ
Ç
È
É
Ê
Ë
Ì
Í
Î
Ï
Ð
Ñ
Ò
Ó
Ô
Õ
Ö

Ø
Ù
Ú
Û
Ü
Ý
Þ
ß
à
á
â
ã
ä
å
æ
ç
è
é
ê
ë
ì
í
î
ï

%c0
%c1
%c2
%c3
%c4
%c5
%c6
%c7
%c8
%c9
%ca
%cb
%cc
%cd
%ce
%cf
%d0
%d1
%d2
%d3
%d4
%d5
%d6
%d7
%d8
%d9
%da
%db
%dc
%dd
%de
%df
%e0
%e1
%e2
%e3
%e4
%e5
%e6
%e7
%e8
%e9
%ea
%eb
%ec
%ed
%ee
%ef
ð
ñ
ò
ó
ô
õ
ö
÷
ø
ù
ú
û
ü
ý
þ
ÿ
%f0
%f1
%f2
%f3
%f4
%f5
%f6
%f7
%f8
%f9
%fa
%fb
%fc
%fd
%fe
%ff

Adicionando as colunas direto no find tanto para tabela, belongsTo ou hasMany com bindModel

As perguntas mais comuns é como faço para restringir a quantidade de colunas que traz na minha busca de uma tabela específica.

Exemplo de Tabelas:

Pagina – id, nome, data_cadastro
Promocao – id, id_pagina, nome, valor, data_cadastro
PromocaoConteudo – id, id_promocao, conteudo, data_cadastro

 

Então quando buscar a promoção teremos:

belongsTo = ‘Pagina’;
hasMany = ‘PromocaoConteudo’;

 

Estes exemplos abaixo, imaginamos que as tabelas já estão vinculadas na Model.

 

Trazendo tudo de tudo:
$promocoes = $this->Promocao->find(‘all’);

 

Vamos imaginar que queira somente algumas colunas de cada tabela que esteja vinculada a Promoção.

$this->Promocao->bindModel(array(‘hasMany’=>array(‘PromocaoConteudo’=>array(‘fields’=>array(‘PromocaoConteudo.conteudo’)))));
$promocoes = $this->Promocao->find(‘all’, array(‘fields’=>array(‘Promocao.nome’,’Promocao.valor’,’Pagina.nome’)));

 

Veja que quando é um BelongsTo é possível colocar nos fields do próprio find da promoção, mas quando é um HasMany, é necessário colocar com o bind como se fosse fazer o vínculo novamente.